bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#60252: 29.0.60; help-fns--describe-function-or-command-prompt asks f


From: Eli Zaretskii
Subject: bug#60252: 29.0.60; help-fns--describe-function-or-command-prompt asks for confirmation
Date: Sat, 24 Dec 2022 08:43:49 +0200

> From: Drew Adams <drew.adams@oracle.com>
> CC: "gregory@heytings.org" <gregory@heytings.org>,
>         "rudalics@gmx.at"
>       <rudalics@gmx.at>,
>         "60252@debbugs.gnu.org" <60252@debbugs.gnu.org>
> Date: Fri, 23 Dec 2022 20:45:01 +0000
> 
> Why?  Why change the standard behavior after 40+
> years?  Why should users have to find "some way to
> get the old behavior back"?

The reason is explained in the change log (and now also in NEWS).

> Why not provide a new command for the new behavior,
> and let users opt _in_ by binding that, if they
> want to, in place of `minibuffer-complete-and-exit'?
> Why make users opt _out_ to get the same behavior
> they've enjoyed for decades?

Because I think the previous behavior was a minor bug, and the new one
is better.

> And if it's the command itself that has a new
> behavior, what about 3rd-party code that expects
> it to have the same, longstanding behavior?

The behavior here is only visible to users, not to 3rd-party code.
This is interactive behavior, and various other commands already
behave like that, have been behaving like that for ages.

> And no, I don't see - in this bug thread - any
> discussion or description of the behavior change
> (beyond what Martin reported).  In particular, I
> see no "why".  Is there perhaps such a discussion
> in emacs-devel, which you would please point to?

There's no discussion of why, but whether this behavior is better than
the old one.  That is the only thing that is on the table.





reply via email to

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