[Top][All Lists]

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

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

From: David Kastrup
Subject: Re: Multi-tty design (Re: Reordering etc/NEWS)
Date: Sun, 20 May 2007 11:04:07 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux)

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" ...
> This code is fine.

>> 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 the way this addition is done is by virtue of "setenv", we can
cater for it.  And this only concerns variables which are treated

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

As written in a separate posting: I'd prefer not to have different
notions of terminal-local and client-local.  But it may be possible to
make both the same by letting terminal-locality include the client as
a differentiating factor as well.

David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

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