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

[Karoly Lorentey <karoly@lorentey.hu>]

[-- Attachment #1.1: Type: text/plain, Size: 6966 bytes --]

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.

Clearly I won't convince you by repeating the same arguments over and
over, and you will definitely not convince me either.  There is no point
in arguing for the sake of arguing.  I throw in the towel, you win.
Congratulations.

Now that this area is finally taken care of, let us choose and discuss
another part of multi-tty design instead.

* * *

I'm really not interested in arguing about environments any more, but
since I have already written my response below, I'll post it for reference.

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

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

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

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

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

> and it is quite simpler than your proposals.

Explain it in a single short sentence then.

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

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

Huh?

>>> And it will also cause a lot of
>>> inconsistencies that can't really be explained well to the user, like
>>> "compile" behaving differently in windows that are side-by-side.
>> I have explained above why I think this is an invalid argument with
>> terminal-local variables.  If two windows are side by side, then they
>> are on the same terminal.
> 
> I think the above comment belonged to a different model
> (frame-dependent variables and/or complete environment
> terminal/frame-local).

If we have partially local environments, then all frames will share
"non-terminal related" variables, so your side-by-side argument is
invalid.  If we have a consistently local environment, then side-by-side
windows will share their environment by virtue of being on the same
terminal.  I really don't see why you keep bringing this up.

>> OK, so let's do that using my design.  Or yours.
> 
> 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.

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

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

-- 
Karoly


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel