Re: Post-22.1 development?

[David Kastrup]

Stefan Monnier <address@hidden> writes:

>>> I think the right way to do it is to change the multi-tty code's handling of
>>> environment so that it preserves the old behavior (and probably breaks
>>> some of the multi-tty support), then merge into the trunk, then try and fix
>>> the multi-tty part of the breakage.
>
>> I'm not sure exactly what the current breakage is, and why it is a
>
> The "breakage" is that process-environment needs to be sometimes replaced by
> (environment).  This is partly unavoidable.  Since we will have several
> environments, there will need a way for external package to explicitly
> request one or the other.
>
>> problem, but there are a number of environment variables that have come
>> up in this discussion that there is general agreement that they should
>> be terminal local (DISPLAY, TERM).
>
> I don't think the disagreement is about which variables should be
> terminal-local and which shouldn't.  Rather it's about what API to present
> to external packages to manipulate the environment.  `process-environment'
> plus `setenv' does not seem quite sufficient.

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.

This implementation will share all environment variables between
terminals except for the terminal-local ones.  It will keep basically
all the idiosyncratic ways of manipulating the global environment (or
a copy-sequence of it for local manipulations) operative.

And it will make it easy, for those who want to do this, to actually
have no shared environment at all.  Since it will not break existing
ways of accessing the environment, it is a good starting point for
experimenting with both shared as well as disparate environments.

If at one point of time a definite choice for one or the other is
made, a somewhat less tricky API might be developed, and in due time,
this proposal of mine might be faded out (take a few major versions).
It is not a thing of beauty, but it is rather flexible and
backwards-compatible.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum