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

[David Kastrup]

Stefan Monnier <address@hidden> writes:

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

The point more or less being that this change is not really to the
current tty, but to the exported 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'...

> For multi-tty, additionally to that, we could add a new
> terminal-local var (could also be read-only, for all I know) called
> `terminal-environment' which contains the environment inherited from
> a particular client.  Then we could add a
> `terminal-environment-filter' variable which determines which
> environment variables are taken from `initial-environment' and which
> from `terminal-environment' when building the environment of a new
> subprocess.

Well, the new idea here is that you want to keep the whole environment
from the client around in some manner even though we might choose not
to use it.

If we ultimately decide to only bother with named terminal-relevant
variables, we can save ourselves the bandwidth to store everything.

But until we have converged to an opinion about that, wasting the
bandwidth and storage in the version to be merged into the trunk does
not seem to be a concern, so this proposal seems like a good idea at
the moment.

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

-- 
David Kastrup