emacs-devel
[Top][All Lists]
Advanced

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

Re: Post-22.1 development?


From: Chong Yidong
Subject: Re: Post-22.1 development?
Date: Tue, 12 Jun 2007 19:38:33 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux)

David Kastrup <address@hidden> writes:

> The proposal was to have process-environment a terminal-local
> variable.  It is set up starting with its own values of DISPLAY and
> TERM.  Each last terminal-local cons-cell has a cdr of
> global-process-environment.  This is a "shared tail" starting with the
> empty string "" (which is an environment element satisfying stringp,
> but not matching any useful string pattern).  setenv will use setcar
> to replace an existing environment variable definition it finds in
> process-environment, and will append non-existing definitions at the
> end of process-environment.

I think it's a bad idea to use a shared tail in this way.  I can't
think of anywhere else in Emacs where this kind of convoluted setup is
used, and it seems to go against the way similar problems are solved
elsewhere in Emacs.

There are two clean ways to do this is: (i) extend process-environment
so that if a symbol occurs in the list, as opposed to a string, that
symbol names a list whose elements are to be used (as though they had
been inserted in process-environment).  Then the final element for all
default values of process-environment would include the symbol
`global-process-environment'; or (ii) extend process-environment so
that an element of `t' means "the global value of this variable"
(similar to hook variables).

Either of these approaches would be backward compatible for
third-party than the shared-tail idea, but IMHO the gain in
cleanliness more than makes up for it.




reply via email to

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