[Top][All Lists]

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

Re: Confused by y-or-n-p

From: Stefan Monnier
Subject: Re: Confused by y-or-n-p
Date: Thu, 07 Jan 2021 21:10:27 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

> Alas, this is not what is happening there.  The old behavior has been lost,
> and the developer who initiated these changes still firmly believes that
> the old behavior is "an ad hoc unsystematic mess, not worthy even of being
> called a behaviour", that it is "chaotic", that it is an "abstruse "design"
> [that] can only have arisen by accident", that it "would get rejected out
> of hand, and indeed ridiculed" if it were proposed now.  In spite of this,
> an approximation of the old behavior is now planned, and I'm supposed to
> document where that current approximation differs from the old behavior, to
> fix the current approximation.  There is of course no chance that the
> behavior of an UI element as complex as the minibuffer could ever be
> recovered by working that way.

I don't always agree with Alan, but I think in this case his analysis is
about right (tho his wording may be less diplomatic than I'd put it):
based on looking at the code, I think it's clear that the old behavior
was not the result of conscious design, but rather the result of ad-hoc
fixes for specific situations.

Based on the experience with the new code, I agree with you that the old
behavior, while ad-hoc, was a fairly good middle-ground.  But I think
it's valuable to work back from that old ad-hoc solution and try and
re-implement it in a more "conscious design" way.

The end result will probably not be 100% identical, but it should help
us get a code we understand better, compared to the old code whose logic
was very much unclear.

IOW, I think the right way to look at it is as a refactoring, which
clarifies the code and brings new alternative behaviors.


reply via email to

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