[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stefan Monnier
Subject: Re: Multi-tty design (Re: Reordering etc/NEWS)
Date: Fri, 18 May 2007 12:27:09 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux)

>>> For everything that is not terminal-related, nothing but a single
>>> environment makes sense, I think.
>> Might be.  But both the TERM and the DISPLAY variables at least need
>> to be adjusted in subprocesses compared to what they were in Emacs's
>> own environment.  This is true regardless of multi-tty.

> Agreed.  The TERM adjustment in some of Emacs' code currently is done
> using
> (let ((process-environment (copy-sequence process-environment)))
>   (setenv "TERM" ...

This code is fine.  The problem comes fro code which does *not* touch TERM,
and hence the subprocess thinks it's running in an `xterm' (for example)
whereas it's really running on an absolutely dumb "terminal", so it may
choose to use color escapes and things like that where they're
not appropriate.

> The point more or less being that this change is not really to the
> current tty, but to the exported tty.

This is also valid for subprocess run without a tty.

>> And furthermore, for the TERM var, we both want to change it in
>> subprocesses and keep it for reference.  So (still ignoring
>> mutli-tty), it would make sense to so something such as introduce a
>> new var (could be read-only) say `initial-environment'.
>> `process-environment' could start as empty and the environment
>> passed to subprocesses would be the combination of
>> `process-environment' and `initial-environment', where
>> `process-environment' entries would take precedence over entries
>> from `initial-environment'.

> My proposal was more or less the same, but with `process-environment'
> and `initial-environment' being named `terminal-environment' and
> `process-environment', respectively.


>> This would break your AUCTeX code in a similar way to the current
>> multi-tty code, but again, it's easy to fix: just loop over
>> `initial-environment' instead of `process-environment'.

> Which is easier if `initial-environment' is called
> `process-environment'...

Well, the opposite is true for existing code that adds stuff to
`process-environment'.  I believe such code is a lot more widespread.

>> If you want this variable to be client-local instead of
>> terminal-local, then just make it a global alist associating clients
>> to their environments.

> The problem is the following: if we get another client into an
> existing terminal, do we update terminal-environment or not?

If you think this is a problem, then you want terminal-environment to be
client-local rather than terminal-local.  You may then want to call it
client-environment-alist.  It's not like it's difficult to implement: it's
all managed in server.el, except the "lookup through `foo-filter'" which
might be done in the C code when building the environment of
a new subprocess.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]