[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Post-22.1 development?
From: |
David Kastrup |
Subject: |
Re: Post-22.1 development? |
Date: |
Wed, 13 Jun 2007 20:44:36 +0200 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) |
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
- Re: Post-22.1 development?, (continued)
- Re: Post-22.1 development?, Richard Stallman, 2007/06/13
- Re: Post-22.1 development?, Richard Stallman, 2007/06/12
- Re: Post-22.1 development?, Stefan Monnier, 2007/06/12
- Re: Post-22.1 development?, Jason Rumney, 2007/06/12
- Re: Post-22.1 development?, Stefan Monnier, 2007/06/12
- Re: Post-22.1 development?, David Kastrup, 2007/06/12
- Re: Post-22.1 development?, Chong Yidong, 2007/06/12
- Re: Post-22.1 development?, Richard Stallman, 2007/06/13
- Re: Post-22.1 development?, Chong Yidong, 2007/06/13
- Re: Post-22.1 development?, David Kastrup, 2007/06/13
- Re: Post-22.1 development?,
David Kastrup <=
- Re: Post-22.1 development?, Chong Yidong, 2007/06/13
- Re: Post-22.1 development?, David Kastrup, 2007/06/13
- Re: Post-22.1 development?, Jeremy Maitin-Shepard, 2007/06/13
- Re: Post-22.1 development?, Miles Bader, 2007/06/14
- Re: Post-22.1 development?, David Kastrup, 2007/06/14
- Re: Post-22.1 development?, Miles Bader, 2007/06/14
- Re: Post-22.1 development?, David Kastrup, 2007/06/14
- Re: Post-22.1 development?, Miles Bader, 2007/06/14
- Re: Post-22.1 development?, David Kastrup, 2007/06/14
- Re: Post-22.1 development?, Miles Bader, 2007/06/14