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

[David Kastrup <dak@gnu.org>]

Karoly Lorentey <karoly@lorentey.hu> writes:

> David Kastrup wrote:
>>> (Emacs may have been running in the background for weeks, and I may
>>> have just started working on my brand new TeX file in a recently
>>> started emacsclient session.)  Both viewpoints should be catered
>>> for.
>> 
>> I disagree.  If a viewpoint can't be catered for without breaking a
>> _lot_ of things and guarantees, catering for it might be a bad idea.
>
> OK, I give up in disgust.  Do whatever you want.  I mean it: go ahead
> and implement whatever environment semantics you find most appropriate.
>  I have presented all my best reasons why I think we should support
> local environments.  I have even proposed what I think was a reasonable
> compromise.  We simply can not reach a common ground if you keep
> discarding my entire viewpoint and use-cases.

I don't see that I do.  Presenting existing use-cases and problems
with them does not mean that I discard your views and approaches.  It
just means that I don't consider them optimal.

> Clearly I won't convince you by repeating the same arguments over
> and over, and you will definitely not convince me either.

A pity if you disregard the existing typical use cases.

> There is no point in arguing for the sake of arguing.  I throw in
> the towel, you win.  Congratulations.

This is not about winning.  I'd actually be glad to lose in every
respect: if you (or somebody else) came up with a solution that beat
all my concerns and propositions.

>> There is lots of Elisp code that does not even run in a frame:
>> network buffers, spell check buffers, background processes and the
>> like.
>
> This code will also work fine for single-terminal users.  All
> existing code would work fine for single-terminal users.
> Single-terminal users will not run into regressions.  We are
> backward compatible.

Uh, but we don't want to have this code break in the multi-tty case.
Let's distinguish two goals here:

a) when a merge into trunk becomes acceptable.  If the single-tty case
works as previously, this will not disrupt people working on other
things.
b) the design of the final code.  There is no point in having "no
regression in the single-tty case" when the multi-tty case does not
have consistent behavior.  And if we have to change the design again,
this might destabilize the trunk temporarily again.  So we want to
have the design more or less in a state where we don't expect many
more disruptive changes.

> I think you are vastly overemphasizing the importance of environment
> variables in general and "future compatibility" in particular.

There is no point in not doing things as good as possible.

>>> One deviation in the multi-terminal case is that code like
>>>
>>> 	(let ((oldval (getenv "FOO"))
>>> 	  (setenv "FOO" "fred")
>>> 	  (unwind-protect
>>> 		...
>>> 	     (setenv "FOO" oldval))
>>>
>>> will change the value of FOO on all terminals but the current one as
>>> a new side effect.  This is, I believe, acceptable.  Some code
>>> adaptation to make existing code able to take advantage of the new
>>> feature set is inevitable.  We can simply document this concern and
>>> suggest solutions (e.g., let-binding `process-environment' instead,
>>> or adding a standard macro that would save and restore
>>> `process-environment' on all terminals.) in the NEWS file, or
>>> wherever we provide an upgrade guide for package writers.
>> 
>> Huh?  Let-binding process-environment would not keep your
>> setenv-implementation from iterating through the terminals and/or
>> keeping score of environment changes to apply, would it?
>
> On the other hand, let-binding process-environment and consing in
> front of it will be an appropriate solution in some of the cases.
> That's what I meant.

If we can detect that process-environment is let-bound (instead of
terminal-local), setenv might refrain from touching other terminals.
That might make your approach work equivalently without having to use
the shared tail hack.

>>>> manipulation of process-environment happens almost
>>>> exclusively through setenv.
>>> In the new design, this will work unchanged in multi-terminal
>>> sessions as well.
>> 
>> It won't for temporary changes.
>
> I do not care.  Single-terminal users will not be affected.

If we don't care for multi-terminal users, we would not be working on
multi-tty in the first place.

>>> I think this solution would be both incompatible and much too
>>> complex.
>> 
>> Interesting.  It is actually compatible with existing code (except
>> those setting the TERM variable if we agree that this is one of the
>> terminal-local ones),
>
> I'm sorry, but this must be a new sense of the word "compatible" I was
> not previously aware of.

Well, tit for tat...

>> and it is quite simpler than your proposals.
>
> Explain it in a single short sentence then.

The environment passed to processes consists of the values in the
terminal-local variable terminal-process-environment and those of the
global variable process-environment, with values in
terminal-process-environment taking priority.

>> The main disadvantage is that it has _one_ "Huh?" factor: setting a
>> terminal-related variable with setenv will not propagate to called
>> processes by default.
>
> That's a pretty big Huh? for me.  This is a cute, fat little Huh?
> oppurtunity even for our sacred single-terminal users.

Yes.  That's why I say I'd like see someone beat my approach.

>> In contrast, your proposals have a _lot_ more "Huh?" factors.
>
> Huh?

They make setenv quite complex, and process-environment is quite more
difficult to interpret and manipulate.

>> If you can improve your design to a point where the
>> (let ((process-environment (copy-sequence process-environment)))
>>   (setenv "..."
>>   (setenv "..."
>>   (start-process ...
>> ))
>> 
>> scenario accepts setenv for terminal-local variables without
>> propagating them elsewhere, where
>> (setenv "..."
>> alone will affect the environment everywhere (except where
>> terminal-specific variables are concerned) and there is not a lot of
>> background stuff going on that is hard to explain, then I would not
>> mind dropping my proposal.
>
> I'm really not interested whatsoever in keeping the above code work
> in multi-terminal sessions.  However, you were quite effective in
> convincing me that single-terminal users must not be affected in any
> way by multi-tty features.

There is no point in having existing code break in multi-tty settings
"only": that way many people will not notice that their code does not
work on multi-tty when it does on single-tty.

"Don't break on single-tty" is important for the merge to the trunk,
but it is pointless as a final goal: in the final state, we would
likely be better off if things break under similar conditions in
multi-tty and single-tty.

>>> The new design can be basically explained in one short sentence:
>>> "process-environment is terminal-local, but setenv affects all
>>> terminals."
>> 
>> But we don't want a setenv DISPLAY to affect all terminals, 
>
> Actually, I do.  If I manually M-x setenv DISPLAY, then I do that
> for a good reason.

"Manually".  setenv is called also non-manually, and in particular
when process-environment might be let-bound.  Can we detect this case?
And are you really sure that if you log into your system remotely,
manually set DISPLAY, work a bit, then log out again, that you would
want your existing session on your home computer retain this manual
setting?

>>>> Disagree.  "Similar packages" pretty much include _all_ packages
>>>> that would have reason to access the environment, so _certainly_
>>>> those packages are relevant to the issue.
>>> Um, nope.  M-x shell is special because it creates a long-term
>>> subprocess with which the user may communicate with inside Emacs,
>>> from different terminals.  X clients manually started from an M-x
>>> shell buffer will appear on the terminal that was active at the time
>>> the shell process was forked.  We can not change this fact, no
>>> matter how hard we tweak Emacs's environment variable handling.
>>> This is why I say the behaviour of M-x shell, M-x term, GUD, ILISP
>>> and friends (a.k.a.  "similar packages") is irrelevant to this
>>> discussion.
>> 
>> Again: disregarding most packages which actually access the
>> environment as "irrelevant" does not seem like a good idea.
>
> You don't seem to understand my point.  Please read my paragraph again.

Can you name some packages using "setenv" that you would not consider
irrelevant in this respect?

-- 
David Kastrup