emacs-devel
[Top][All Lists]
Advanced

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

Re: Multi-tty design


From: David Kastrup
Subject: Re: Multi-tty design
Date: Tue, 15 May 2007 01:29:09 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.51 (gnu/linux)

Nick Roberts <address@hidden> writes:

>  > I have already reverted back my checked-out copy to the trunk.  If
>  > anybody wants to fix the ChangeLog in multi-tty to reflect the last
>  > change and revert of mine, here are the relevant entries I would have
>  > put into lisp/ChangeLog:
>  > 
>  > 2007-05-14  David Kastrup  <address@hidden>
>  > 
>  >    * env.el (getenv): Fix reverted by demand of Dan Nicolaescu
>  >    because it exposes further problems.
>  > 
>  > 2007-05-13  David Kastrup  <address@hidden>
>  > 
>  >    * env.el (getenv): Pass frame to getenv-internal.
>
> I can't comment on the technical merit of your fix, for all I know
> it may indeed be right.

It is right on the surface: I already explained in detail my opinion
about the whole idea: my preferred solution would be to revert most
changes to env.el since the whole idea is not sound.  But if one is
convinced that it is the right idea, one needs to start by letting the
functions actually do what they claim to do.

But if we don't bother about actually _implementing_ the announced
design, evaluating it is not possible.  That's cheating.

> I just don't think your bullish approach is effective and that you
> need to wait for others to agree with your ideas before rushing
> ahead with them.

They are free to approach this in whatever pace they want to.  It's
not like I don't have more rewarding stuff piling up, anyway.

A "bullish" approach would have been replacing the code by code of my
own design, rather than replacing it by the announced and intended,
but not properly implemented design.  I have my doubts that it _can_
be properly implemented, but I was at least willing to give it a shot.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

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