all messages for Emacs-related lists mirrored at yhetil.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

* 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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.