emacs-devel
[Top][All Lists]
Advanced

[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 10:24:29 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux)

>> I didn't know that the MS-DOS port does make Emacs's terminal
>> available directly to its subprocesses, but that can be easily
>> accomodated.

> I don't know about the port actually, and it is not a matter of making
> the terminal available as much as the subprocess just taking it, I
> think.

You're nitpicking at my choice of word.  It deosn't matter whether Emacs
*makes* the terminal available" or whether the terminal just *is* available
by virtue of the "OS".  The point is just that this is a special case that
can be easily accomodated (by not scrapping the TERM var in that case).

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

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

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

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.

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.


        Stefan




reply via email to

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