Re: Post-22.1 development?

[David Kastrup]

Chong Yidong <address@hidden> writes:

> 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 concur it is ugly.  However, it is also expedient in that it lets us
experiment with several concepts of sharing and not sharing
environment variables, _without_ requiring to meddle with unrelated
code until we have settled on one or the other paradigm.

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

It does not work.  setenv is normally supposed to set an environment
variable for _all_ terminals, _unless_ process-environment has been
set to a _copy_ of itself.  The shared tail makes the detach-on-copy
operation work.

> 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

_not_ be backward compatible, you mean.

> third-party than the shared-tail idea, but IMHO the gain in
> cleanliness more than makes up for it.

With that kind of change, we might equally well _remove_
process-environment altogether in favor of some other accessor
functions.  The effect will be the same: pretty much _everything_
looking at process-environment will break.

It might be an API of choice in the long run.  In the mean time, the
shared tail _implementation_ provides a migration strategy.  We can
(once we find ourselves converging to a preferred behavior) introduce
accessor functions at some point of time, and then start deprecating
process-environment.  But that's a long haul.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum