Re: Confused by y-or-n-p

[Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>]

>> 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.

>
> 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.

>> 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.

>
> 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.

>
> 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.