unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: "rudalics@gmx.at" <rudalics@gmx.at>,
	"gregory@heytings.org" <gregory@heytings.org>,
	"60252@debbugs.gnu.org" <60252@debbugs.gnu.org>
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	[thread overview]
Message-ID: <SJ0PR10MB5488BF716F9AC5ED12C03B78F3E99@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <838riy6jvs.fsf@gnu.org>

> > 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	other threads:[~2022-12-23 20:45 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-22  9:21 bug#60252: 29.0.60; help-fns--describe-function-or-command-prompt asks for confirmation martin rudalics
2022-12-22 10:54 ` Eli Zaretskii
2022-12-22 14:54   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-22 15:30     ` Eli Zaretskii
2022-12-22 16:41       ` martin rudalics
2022-12-22 16:48       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-22 16:53         ` Eli Zaretskii
2022-12-22 21:14           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-23  7:26             ` Eli Zaretskii
2022-12-22 21:32 ` Gregory Heytings
2022-12-22 23:25   ` Drew Adams
2022-12-23  7:02     ` Juri Linkov
2022-12-23 14:43       ` Eli Zaretskii
2022-12-23 16:36       ` Drew Adams
2022-12-23  7:32     ` Eli Zaretskii
2022-12-23 16:47       ` Drew Adams
2022-12-23 18:43         ` Eli Zaretskii
2022-12-23 20:45           ` Drew Adams [this message]
2022-12-24  6:43             ` Eli Zaretskii
2022-12-23  7:24   ` Eli Zaretskii
2022-12-23 11:21     ` Gregory Heytings
2022-12-23 12:39       ` Eli Zaretskii
2022-12-23  8:33   ` martin rudalics
2022-12-23 11:19     ` Gregory Heytings
2022-12-24  8:38       ` martin rudalics
2022-12-23 11:34     ` Eli Zaretskii
2022-12-24  8:38       ` martin rudalics

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SJ0PR10MB5488BF716F9AC5ED12C03B78F3E99@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=60252@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=gregory@heytings.org \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).