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

[Karoly Lorentey]

David Kastrup wrote:
>>>> 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.  

I'm sorry; I thought we are talking about a piece of code that let-binds
process-environment.   Clearly I was wrong.

If the code uses setenv to permanently set variables, then it would work
fine on multi-terminal sessions in my proposed terminal-local design.
For single-terminal users, the code will remain working no matter what
it does.

> It would only work unchanged with
> terminal-local process-environment if the non-terminal local tail of
> process-environment was shared.  

The actual underlying requirement is that `setenv' should affect all
existing and future terminals.  Tail-merging is an implementation choice.

> 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.

I disagree.  It is actually a very simple and predictable system that's
easy to explain.

>> 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...

I have withdrawn the current implementation, and no longer want to push
for it.  I'm not interesting in arguing about its features any more.

> 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.

So what?  That's not a bug per se.

> 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.

I say we must support both.  Clearly, people are divided on the issue.
Once we have greater experience with these features, we can standardize
on the right thing.  I doubt we will be able to convince each other now.

> 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.

Frames are associated with their clients by their 'client parameter.
Buffers for files opened from the command line of emacsclient are
recorded in `server-clients'.  The behaviour of C-# should match
whatever is on the trunk.

> Another possibility would be to diss C-x # completely.  

I'm all for that, but I guess existing emacsclient users may complain,
and there is really no reason to remove it.

> 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.

OK, I agree.

-- 
Karoly

signature.asc
Description: OpenPGP digital signature