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

[David Kastrup]

Karoly Lorentey <address@hidden> writes:

> Stefan Monnier wrote:
>>> I do not feel this is a particularly important issue, but sure.  Do
>>> people use -display often?  I usually simply change DISPLAY directly.
>> 
>> I use make-frame-on-display, and in this case it's a lot more important.
>
> Thankfully, it is easy to add support for it.
>
>>> 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.
>> 
>> I'm not sure I understand: wouldn't this choice break the mentioned AUCTeX
>> code, then?
>
> No, not at all.  The special environment may be set up for a single
> client/terminal/whatever only, but I doubt the code switches frames
> before it starts whatever subprocess it wants to start in the temporary
> environment.

Uh what?  This is code being run when Emacs is started up, namely when
custom-set-variables is called.  It would only work unchanged with
terminal-local process-environment if the non-terminal local tail of
process-environment was shared.  And that is a solution which has some
appeal because of its cleverness, but which is clearly too clever and
fragile to make for something one wants to document and use.

>> Also, while I'm here, why do you use frame-local bindings rather than
>> terminal-local bindings (maybe via a new terminal-local variable
>> `local-process-environment')?
>
> It is to enable separate environments in cases such as this:
>
> xterm #1:
>       $ export FOO=23
>       $ emacsclient  // new X frame
>
> xterm #2:
>       $ export FOO=42
>       $ emacsclient  // another one, on the same display
>
> I find this nice, but others loathe it, so it probably isn't worth the
> added complexity.  The issue is moot now anyway. :-)

I don't find it nice.  I don't see how the issue is moot unless I have
been quite convincing...

Note that two emacsclient processes (and possibly an emacs -nw)
started in the same tty will all share their settings (which I
consider reasonable), while starting, say, two emacsclient processes
in two different "screen" ttys will each give them their own settings.

I really feel we should restrict that to terminal-related variables by
default.  That's simple to understand and has no strong drawbacks that
I can see.

The one thing which I don't have a clear idea how to solve
consistently is what frames/windows/emacsclient sessions C-x # is
going to close and what buffers to discard.  But maybe that can be
solved with a single variable that associates a "session" with frames
and buffers.

Another possibility would be to diss C-x # completely.  However,
killing an associated buffer at least for the simplest use case

emacsclient filename
edit the file
C-x # or similar

seems desirable.  But I think that this issue is separate, and should
be.

-- 
David Kastrup