Re: multi-tty branch created

[Károly Lőrentey]

David Kastrup wrote:
> "Károly Lőrentey" <address@hidden> writes:
>>> emacsclient operation in multitty is different as compared to
>>> previously.  So people can't avoid multitty completely, meaning
>>> that we can't bluntly state "situation can't be worse than
>>> previously, no regression" but need to evaluate multitty somewhat
>>> more closely before finding it suited for trunk, even if the
>>> compilation problems on DOS/Windows/Mac have been tackled.
>> Hold your horses.
> 
> You would not want me to: my concerns are likely similar to those of
> others, so you want to get them discussed and refuted.

Yes.  But saying that multi-tty is somehow more suspect because it
changes emacsclient sounds strange to me.  Well of course it changes it.
 The entire point of the branch is to fix how emacsclient works.  D'oh!

I was arguing that all the existing functionality is retained by design.
 If there is a feature that was lost, then that's a bug.

>> There is always "emacsclient --current-frame" to prevent emacsclient
>> from creating a new terminal.  This retains much of the
>> functionality of the original emacsclient, including, I believe,
>> things like C-#, and does not use multi-tty features.
> 
> Still, environments do no longer work the same even if you don't use
> multi-tty features.

Yes they do.  "emacsclient --current-frame" does not create a new set of
local environment variables, but reuses the original environment of the
Emacs process.  It should work exactly the same as emacsclient on the
trunk.  Does it not?

As I said, the one and only truly incompatible change in the multi-tty
branch is that even without any emacsclient connections,
`process-environment' is nil by default, and there is a new
`environment' function for listing all variables.  I don't think you can
argue with a straight face that all hell will break loose if we make
such a change, or that it is unacceptable to make our hackers adapt
existing code for these changes.  After all, we are working on a new
major version, and there aren't all that many Emacs packages that care
about environment variables.  A sizable portion of the few that do
simply call getenv and setenv, or let-bind `process-environment', which
works fine with multi-tty as well.  I have presented my reasons for the
change; I still think the client-local environment semantics are the
right way to go, although the implementation may be improved.

>> Keep in mind that improving emacsclient behaviour is one of the
>> primary results of the multi-tty branch.
> 
> But we don't want secondary results interfering with the work of those
> who don't make use of the primary results.

As I have explained, "emacsclient --current-frame" is the way people can
get back the original behaviour.  If there are serious bugs, the legions
of people who're now testing multi-tty will likely report them before
the merge.  Is that not sufficient to prevent undue interference?

I encourage people on supported platforms to try their favourite
emacsclient options in the multi-tty branch, and report anything that
breaks.

-- 
Karoly

signature.asc
Description: OpenPGP digital signature