[Top][All Lists]

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

Re: Confused by y-or-n-p

From: Alan Mackenzie
Subject: Re: Confused by y-or-n-p
Date: Mon, 4 Jan 2021 12:34:56 +0000

Hello, Gregory.

On Mon, Jan 04, 2021 at 11:35:19 +0000, Gregory Heytings via Emacs development 
discussions. wrote:

> >> That's not correct, see for example the thread "Stop frames stealing 
> >> eachothers' minibuffers!", in which the longstanding behavior of Emacs' 
> >> minibuffers, which are arguably a central piece of Emacs' UI, is being 
> >> modified on the pretext that it is "unsystematic", without any 
> >> argument, and in spite of the fact that hundreds and thousands of users 
> >> have been using it without complaining about that supposed 
> >> "unsystematicity".

> > There has been argument, on that other thread, which you have taken part 
> > in, and which now extends to nearly 200 posts.

> I haven't seen a single argument in that thread to remove the current 
> behavior.  I've only seen an argument that you (and only you AFAICS) don't 
> like it.

I suggest you reread that thread, long though it is, with some care.
There were strong arguments expressed there, for improving the then
current behaviour.

> > That few people complained about the old behaviour is not a strong 
> > argument against improving it.  Many improvements to Emacs are made 
> > without being prompted by widespread complaints.

> I never ever objected the idea of improving the minibuffer behavior.  I 
> strongly objected the idea of removing its longstanding behavior.

As I have just said, your objections have been taken into account and
acted upon.  I don't really want to get drawn here into detailled
discussion which really belongs on that other thread, but would point out
that that "longstanding behaviour" which you seem so attached to appears
to be an ad hoc unsystematic mess resulting from a lack of systematic
attention.  I have now given it that attention.

> >> I repeatedly explained that the old behavior should remain available. 
> >> Initially the change explicitly removed the old behavior: "The old 
> >> [behavior] is no longer available."  The latest patch sent yesterday, 
> >> only promises to "approximate" the old behavior.

> > It would thus appear that you are an "important enough person".

> No, quite the contrary.

Forgive me if I become uncustomarily blunt and personal, but it seems you
are determined to find the worst possible interpretation of everything,
and your replies to so many posts take on an unusually negative tone.

I put the old behaviour back specifically to please you and others like
you, yet your reaction, rather than to thank me, is to criticise that it
is "only an approximation".  And that before you have even tried it out.

Dealing with such negativity is an emotionally draining experience for
me, and I suspect I am not alone here.  One way of coping with this
would be to ignore your posts entirely, but I don't want to do that.

Would you please try to be more positive in your posts, and try to work
together with people to achieve goals, rather than antagonising them.

> > I put the old behaviour back as a result of your representations, 
> > despite not understanding why anybody might want it.

> That's the problem I mentioned in my other email: "because [some users] 
> use Emacs in a way that was not envisioned by the developer who 
> implemented the UI change, and that this UI change breaks their 
> configuration, which relied on the old behavior".  We cannot know what 
> kind of exotic things people do with Emacs, and the only way to ensure 
> that it is stable is to keep the old behavior alongside the new one, at 
> least for some time.  Some time later (one or two major releases later, 
> say) the old behavior can of course be deprecated, with a target release 
> when this will happen.  That gives users the time to adapt their libraries 
> and configurations.  But all of a sudden removing the old behavior and 
> installing a new one is IMO wrong.

The old "behaviour" seems to be an ad hoc unsystematic mess, not worthy
even of being called a behaviour.

> > However, since I've tidied up the C code appreciably, I cannot guarantee 
> > that this behaviour is 100% the same as the old, hence the use of the 
> > word "approximate".

> > Have you tried this patch out, yet?  If there is anything in the 
> > "approximation" which is not close enough, perhaps you could point out 
> > what, so that I might fix it.  Thanks!

> Not yet, I'll do that, but can't promise when.  But the problem is that I 
> am now, and everybody else is now, in a situation where we have to spend a 
> lot of time testing various combinations of commands and to describe what 
> doesn't work anymore, which inevitably leads to very long and boring mails 
> and discussions.

How is that a problem?  Nobody is forcing you into such discussions.  At
the cutting edge of development, there are bound to be new things, there
are bound to be old things let go, and there are bound to be
controversies.  That is the very essence of development.  People are
grateful for the feedback you give, but nobody is forcing you into doing

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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