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

[David Kastrup]

Karoly Lorentey <address@hidden> writes:

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

I was talking elsewhere of that.  The AUCTeX code was an example for
something that goes through the process-environment once and does
changes based on what it finds there.  This was basically an example
for code that would not work predictably with terminal-local values of
TEXINPUT*.  So it was making a case for having a global environment by
default.

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

How come that I am arguing against my idea and you are arguing for it?

Ok, my main objection was that it is hard to conceive how to set up a
new terminal, namely where the shared tail starts.

If the shared tail, however, has its own symbol (as I actually did
propose, naming it global-process-environment), this is not hard to
do.

One would still have to do the following:
a) have a list of terminal-local variable names.  When the environment
is first read in, those are picked out from global-process-environment
and put into the terminal-local list instead.  This might have to
include unset variables in some form.  Probably as "DISPLAY=" since
for shells and applications, an empty variable and a deleted variable
are identical.  Just using "DISPLAY" alone might possibly be
misinterpreted by current readers of process-environment.

b) have setenv work also on unset variables, and make sure that it
does not clobber the global-process-environment situation.  This might
be non-trivial if one requests deletion of the first environment
variable from global-process-environment: this deletion would not work
on the shared tails.  So we might want to start
global-process-environment with a dummy entry that never gets removed.

Personally, I would consider this sort of implementation ugly.

However, it has two advantages: process-environment will tell the
whole story of the environment on a given terminal.  Old code will
very likely work.

And both the variants with terminal-local complete environments and
terminal-local partial environments can be implemented with just a few
lines of code.

So people will have a way to test both behaviors.  If at the end of
the testing one clear choice emerges, one might consider implementing
it in a less hackish manner that will leave the other choice out in
the cold.

>> 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 was just explaining some consequences of the pure terminal-local (as
opposed to client-local) approach.  I don't consider it a bug, and so
much the better if you don't, either.

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

Well, my "shared tail hack" offers a path to get experience with both
approaches.  Both approaches from you and me would require existing
code to be adapted (and possibly in different ways for each approach),
and the hack will probably spare us from most of that while the jury
is still out.

-- 
David Kastrup