Re: Multi-tty design (Re: Reordering etc/NEWS)

[rentey <address@hidden>]

David Kastrup wrote:
> I would argue that an Emacs started with
> DISPLAY=:0.0 emacs -display :1.0
> should export an environment variable DISPLAY=:1.0 to its subprocesses
> unless explicitly overridden.  This is somewhat complicated by the
> situation given with
> DISPLAY=:0.0 emacs -nw
> In this case, I would still want to export :0.0 to subprocesses, and
> in the case
> DISPLAY=:0.0 emacs -nw -display :1.0
> I would suggest a non-graphical instance of Emacs exporting a DISPLAY
> variable of :1.0.

I do not feel this is a particularly important issue, but sure.  Do
people use -display often?  I usually simply change DISPLAY directly.

> Where Emacs' behavior depends on such variables, it might make sense
> to let them influence Emacs' behavior in terminal-local entities, and
> have a default export mechanism based on those terminal-local recorded
> settings.  It would seem desirable to have parallel terminal sessions
> from an iso-8859-1 terminal and a utf-8 terminal into Emacs possible
> without getting garbled screens.

Yes, Emacs behaviour is different on different terminals according  to
TERM, LANG, LC_*, and others.  But this isn't really a matter of having
{terminal,client,frame}-local environment variables.  The environment of
emacsclient can remain available in `server-clients', and server.el can
do the right thing even if we choose not to allow subprocesses to
inherit local environments at all.

So having a both UTF-8 and Latin-1 tty sessions will remain possible
with or without local environment variables.

>> I tend to think of emacsclient as "connect to the main Emacs
>> process", so I tend to expect it to work in the environment of the
>> main Emacs process.  You seem to think of it as "pretend you're a
>> normal Emacs process, just quick-started", so you expect a slightly
>> different behavior.
> 
> And I don't think that Emacs can actually be even close to satisfying
> the second paradigm, so there is little sense in doing a half-baked
> version of it and failing.

Well, there is no need to guess about that; I personally use emacsclient
exactly as I would use a full-blown editor.  In its current state, the
branch provides a good enough approximation to this paradigm that I
never notice I am not working in a local instance.

> I disagree.  If I have two frames side by side displaying the same
> buffer, it will be extremely confusing if using setenv in one frame
> will not have an effect on the other frame when calling commands with
> M-!.

Please try out the branch in practice.  Setenv without a frame parameter
has a global effect; it overrides all local environments, including the
ones created by future connections.

You are objecting to having different behaviour in different frames.
Aren't frame-local Elisp variables equally confusing to you?

>>>     - Furthermore, to me it seems more consistent to have all
>>>     environment variables be local than just a select few of them.
>> I don't find it important, but it doesn't seem to be bad either.
> 
> Disagree.  It makes shell buffers behave totally unpredictable across
> terminals (or even worse, frames): the sequence
> exit RET M-x shell RET
> usually gets rid of environment variables set within the shell
> session.  It would not be nice to have to guess what behavior will
> result.
> 
> AUCTeX, for example, contains code like the following:

AFAICT, apart from having to replace the process-environment reference
with '(environment)', the quoted code will work just fine on the
multi-tty branch.

> We don't want to have _any_ such code just break.

Really?  No incompatible change is ever allowed?  Not even in a new
major version?  I would like to have a second opinion on that from other
developers.

But if that's really the case, we can still make `process-environment'
have a terminal-local binding (with, I assume, DEFVAR_KBOARD), and have
all existing third-party Elisp code continue to work without changes.
Note that this would restrict the available designs considerably: all
environment variables would have to be terminal-local, with no
cherry-picking of DISPLAY.

-- 
Karoly

signature.asc
Description: OpenPGP digital signature