emacs-devel
[Top][All Lists]
Advanced

[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 21:47:16 +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:
>
>>> 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 don't understand what the purpose of this experimentation is.
> What exactly do you want to find out with these "experiments"?

There have been sharp disagreements as to whether or not this
separation is a good idea for unrelated variables, or whether one
would want to share between some clients/terminals/sessions or not.
No agreement could be reached.  Being able to _switch_ will make it
possible for users to work with both approaches, with multiple use
patterns and requirements.  We can then meaningfully poll them at one
point of time.

> Instead of making a change that we might want to completely revamp
> (or, worse, get stuck with an ugly API because it's too much trouble
> to revamp), why not just adopt Stefan's very reasonable plan:
>
>> 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.

Which is pretty much what my proposal is supposed to achieve: preserve
the old behavior.  It is just that I also have taken the step of
proposing a plan how to fix the multi-tty part of the breakage.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

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