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: Drew Adams
Subject: bug#60252: 29.0.60; help-fns--describe-function-or-command-prompt asks for confirmation
Date: Fri, 23 Dec 2022 20:45:01 +0000

> > Gregory suggested that different binding, when
> > Martin asked how to "get the old behavior back".
> >
> > From my understanding, "the old behavior" is that
> > of `minibuffer-complete-and-exit'.  Needing to use
> > `minibuffer-local-must-match-map' to get "the old
> > behavior back" sounded odd to me.  But then no, I
> > don't know what the new (Emacs 29) behavior might be.
> 
> The point is that the behavior of minibuffer-complete-and-exit
> has changed.  This is what this discussion is about.

It sounded to me, from Martin's posts, like the change
in behavior might not be so great (so far), or perhaps
it isn't backward-compatible (so far).

He said, and I agree, that in Emacs 28 (and all the
way back to Day One - at least through Emacs 20), that
`C-h f set-face-a RET' immediately gives you *Help*.
Martin said that in Emacs 29 it no longer does that.

Whether
  * the command bound to `RET' is no longer 
    `minibuffer-complete-and-exit', but is something
    that behaves differently,
or
  * the command bound to `RET' is still
    `minibuffer-complete-and-exit', but that command
    now behaves differently,
the effect is that the behavior is now different.

Why?  Why change the standard behavior after 40+
years?  Why should users have to find "some way to
get the old behavior back"?

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?

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?

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?





reply via email to

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