[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Multi-tty design (Re: Reordering etc/NEWS)
From: |
Karoly Lorentey |
Subject: |
Re: Multi-tty design (Re: Reordering etc/NEWS) |
Date: |
Fri, 18 May 2007 13:55:53 +0200 |
User-agent: |
Thunderbird 2.0.0.0 (Windows/20070326) |
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
signature.asc
Description: OpenPGP digital signature
- Re: Multi-tty design (Re: Reordering etc/NEWS), (continued)
- Re: Multi-tty design (Re: Reordering etc/NEWS), David Kastrup, 2007/05/22
- Re: Multi-tty design (Re: Reordering etc/NEWS), Richard Stallman, 2007/05/22
- Re: Multi-tty design (Re: Reordering etc/NEWS), David Kastrup, 2007/05/22
- Re: Multi-tty design (Re: Reordering etc/NEWS), Richard Stallman, 2007/05/23
- Re: Multi-tty design (Re: Reordering etc/NEWS), David Kastrup, 2007/05/23
- Re: Multi-tty design (Re: Reordering etc/NEWS), Richard Stallman, 2007/05/24
- Re: Multi-tty design (Re: Reordering etc/NEWS), David Kastrup, 2007/05/24
- Re: Multi-tty design (Re: Reordering etc/NEWS), Eli Zaretskii, 2007/05/18
- Re: Multi-tty design (Re: Reordering etc/NEWS), Karoly Lorentey, 2007/05/17
- Re: Multi-tty design (Re: Reordering etc/NEWS), David Kastrup, 2007/05/18
- Re: Multi-tty design (Re: Reordering etc/NEWS),
Karoly Lorentey <=
- Re: Multi-tty design (Re: Reordering etc/NEWS), David Kastrup, 2007/05/18
- Re: Multi-tty design (Re: Reordering etc/NEWS), Karoly Lorentey, 2007/05/18
- Re: Multi-tty design (Re: Reordering etc/NEWS), David Kastrup, 2007/05/18
- Re: Multi-tty design (Re: Reordering etc/NEWS), Richard Stallman, 2007/05/18
- Re: Multi-tty design (Re: Reordering etc/NEWS), rentey <address@hidden>, 2007/05/20
- Re: Multi-tty design (Re: Reordering etc/NEWS), Richard Stallman, 2007/05/12
- Re: Reordering etc/NEWS, Richard Stallman, 2007/05/12
- Re: Reordering etc/NEWS, joakim, 2007/05/10
- Re: Reordering etc/NEWS, Jason Rumney, 2007/05/10
- Multi-tty branch status (Re: Reordering etc/NEWS), Karoly Lorentey, 2007/05/11