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

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

[martin rudalics]

This change

--- a/lisp/help-fns.el
+++ b/lisp/help-fns.el
@@ -229,7 +229,7 @@ help-fns--describe-function-or-command-prompt
                 (lambda (f) (if want-command
                            (commandp f)
                          (or (fboundp f) (get f 'function-documentation))))
-               t nil nil
+               'confirm nil nil
                 (and fn (symbol-name fn)))))
      (unless (equal val "")
        (setq fn (intern val)))

in

commit c12838c73ef161850a081f9ccea6e375b7c2f93b
Author: Stefan Monnier <monnier@iro.umontreal.ca>
Date:   Fri Sep 2 09:54:13 2022 -0400

breaks my working flow as follows: With Emacs 28 when I type

C-h f RET set-face-a RET

I get a help window on ‘set-face-attribute’.  Now I'm asked to
[Confirm].  Kindly add some way to get the old behavior back.

Thanks, martin


In GNU Emacs 29.0.60 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.5,
  cairo version 1.16.0) of 2022-12-16 built on restno
Repository revision: f4b430140f0866f98bbf18b7094348dc64032813
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux 10 (buster)

Configured using:
  'configure --with-gif=ifavailable --with-tiff=ifavailable
  --with-gnutls=no --without-pop --enable-gcc-warnings=warn-only
  --enable-checking=yes,glyphs --enable-check-lisp-object-type=yes
  'CFLAGS=-O0 -g3 -no-pie -Wno-missing-braces''

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GSETTINGS HARFBUZZ JPEG LIBSELINUX MODULES
NOTIFY INOTIFY PDUMPER PNG SECCOMP SOUND THREADS TOOLKIT_SCROLL_BARS X11
XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
   value of $LANG: de_AT.utf8
   value of $XMODIFIERS: @im=ibus
   locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
   tooltip-mode: t
   global-eldoc-mode: t
   eldoc-mode: t
   show-paren-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   line-number-mode: t
   indent-tabs-mode: t
   transient-mark-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date subr-x
cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
emacs)

Memory information:
((conses 16 36067 5652)
  (symbols 48 5123 0)
  (strings 32 13056 1700)
  (string-bytes 1 369122)
  (vectors 16 9292)
  (vector-slots 8 147643 11236)
  (floats 8 22 35)
  (intervals 56 217 0)
  (buffers 976 10))

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

[Eli Zaretskii]

> Date: Thu, 22 Dec 2022 10:21:56 +0100
> From: martin rudalics <rudalics@gmx.at>
> 
> This change
> 
> --- a/lisp/help-fns.el
> +++ b/lisp/help-fns.el
> @@ -229,7 +229,7 @@ help-fns--describe-function-or-command-prompt
>                  (lambda (f) (if want-command
>                             (commandp f)
>                           (or (fboundp f) (get f 'function-documentation))))
> -               t nil nil
> +               'confirm nil nil
>                  (and fn (symbol-name fn)))))
>       (unless (equal val "")
>         (setq fn (intern val)))
> 
> in
> 
> commit c12838c73ef161850a081f9ccea6e375b7c2f93b
> Author: Stefan Monnier <monnier@iro.umontreal.ca>
> Date:   Fri Sep 2 09:54:13 2022 -0400
> 
> breaks my working flow as follows: With Emacs 28 when I type
> 
> C-h f RET set-face-a RET
> 
> I get a help window on ‘set-face-attribute’.  Now I'm asked to
> [Confirm].  Kindly add some way to get the old behavior back.

Stefan, any suggestions for more backward compatibility?

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Stefan, any suggestions for more backward compatibility?

We can presumably try and do a better job in the completion table.
I can't work on it now, tho,


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: martin rudalics <rudalics@gmx.at>,  60252@debbugs.gnu.org
> Date: Thu, 22 Dec 2022 09:54:15 -0500
> 
> > Stefan, any suggestions for more backward compatibility?
> 
> We can presumably try and do a better job in the completion table.
> I can't work on it now, tho,

Thanks.

I'm actually wondering why Martin considers this a backward
incompatibility.  set-face-a cannot be uniquely completed to a single
function name, since there are 3 completion candidates.  So it sounds
like the Emacs 28 behavior was actually a bug, which is now fixed?

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

[martin rudalics]

 > I'm actually wondering why Martin considers this a backward
 > incompatibility.  set-face-a cannot be uniquely completed to a single
 > function name, since there are 3 completion candidates.  So it sounds
 > like the Emacs 28 behavior was actually a bug, which is now fixed?

Heuristically, it worked here for many, many years.  And the prompt to
'Confirm' has my muscle memory react with RET which gets me

user-error: Symbol’s function definition is void: set-face-a

and I have to start all over again.

martin

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> I'm actually wondering why Martin considers this a backward
> incompatibility.  set-face-a cannot be uniquely completed to a single
> function name, since there are 3 completion candidates.

But it can be completed to a string which is an exact match.

> So it sounds like the Emacs 28 behavior was actually a bug,

Whether it was the right behavior or not can be argued, but that's how
"must match" has behaved for many many years (probably at least since
Emacs-19), AFAIK.

> which is now fixed?

We may as well revert that part of my patch.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: rudalics@gmx.at,  60252@debbugs.gnu.org
> Date: Thu, 22 Dec 2022 11:48:13 -0500
> 
> > I'm actually wondering why Martin considers this a backward
> > incompatibility.  set-face-a cannot be uniquely completed to a single
> > function name, since there are 3 completion candidates.
> 
> But it can be completed to a string which is an exact match.
> 
> > So it sounds like the Emacs 28 behavior was actually a bug,
> 
> Whether it was the right behavior or not can be argued, but that's how
> "must match" has behaved for many many years (probably at least since
> Emacs-19), AFAIK.

I meant a behavioral bug, not that the code didn't do what it was told
to do.

> > which is now fixed?
> 
> We may as well revert that part of my patch.

I don't think that would be TRT.  Emacs behaves like that in other
places, so why this one should be different?  Such inconsistency can
confusing.

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> We may as well revert that part of my patch.
> I don't think that would be TRT.  Emacs behaves like that in other
> places, so why this one should be different?  Such inconsistency can
> confusing.

It's quite unusual to ask for the `describe-function` of a symbol that's
not defined as a function and it won't give you very much info.

Or maybe the use of `confirm` should depend of
(and help-enable-autoload (not help-enable-completion-autoload))?


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: rudalics@gmx.at,  60252@debbugs.gnu.org
> Date: Thu, 22 Dec 2022 16:14:04 -0500
> 
> >> We may as well revert that part of my patch.
> > I don't think that would be TRT.  Emacs behaves like that in other
> > places, so why this one should be different?  Such inconsistency can
> > confusing.
> 
> It's quite unusual to ask for the `describe-function` of a symbol that's
> not defined as a function and it won't give you very much info.

I'm afraid of use cases where the user didn't know whether a function
is or isn't defined.  Human memory isn't perfect.  I frequently forget
whether the function is buffer-process or get-buffer-process, for
example.

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

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 317 bytes --]


>
> With Emacs 28 when I type
>
> C-h f RET set-face-a RET
>
> I get a help window on ‘set-face-attribute’.  Now I'm asked to 
> [Confirm].  Kindly add some way to get the old behavior back.
>

I suggest

(define-key minibuffer-local-must-match-map (kbd "RET") #'minibuffer-force-complete-and-exit)

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

[Drew Adams]

> I suggest
> 
> (define-key minibuffer-local-must-match-map (kbd "RET") #'minibuffer-
> force-complete-and-exit)

Why?

Needing to do that is something new.  The binding has
been `minibuffer-complete-and-exit' since Day One.

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

[Juri Linkov]

>> I suggest
>>
>> (define-key minibuffer-local-must-match-map (kbd "RET") #'minibuffer-
>> force-complete-and-exit)
>
> Why?
>
> Needing to do that is something new.  The binding has
> been `minibuffer-complete-and-exit' since Day One.

I tried to check the function bound to RET in the minibuffer,
but in Emacs 29 typing 'C-h f C-h k RET' raises an error:

Debugger entered--Lisp error: (wrong-type-argument consp nil)
  event--posn-at-point()
  event-end(13)
  help--analyze-key("\15" [return] nil)
  #f(compiled-function (x) #<bytecode 0x8dc81a7f13b6e25>)(("\15" . [return]))
  mapcar(#f(compiled-function (x) #<bytecode 0x8dc81a7f13b6e25>) (("\15" . [return])))
  describe-key((("\15" . [return])))
  funcall-interactively(describe-key (("\15" . [return])))
  command-execute(describe-key)
  completing-read-default("Describe function: " help--symbol-completion-table
    #f(compiled-function (f) #<bytecode 0x17c923a28e18507a>) confirm nil nil nil nil)
  help-fns--describe-function-or-command-prompt()
  command-execute(describe-function)

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

[Eli Zaretskii]

> Cc: martin rudalics <rudalics@gmx.at>, Gregory Heytings <gregory@heytings.org>,
>  "60252@debbugs.gnu.org" <60252@debbugs.gnu.org>
> From: Juri Linkov <juri@linkov.net>
> Date: Fri, 23 Dec 2022 09:02:04 +0200
> 
> I tried to check the function bound to RET in the minibuffer,
> but in Emacs 29 typing 'C-h f C-h k RET' raises an error:
> 
> Debugger entered--Lisp error: (wrong-type-argument consp nil)
>   event--posn-at-point()
>   event-end(13)

Thanks, should be fixed now.

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

[Drew Adams]

> >> I suggest
> >> (define-key minibuffer-local-must-match-map (kbd "RET")
> >> #'minibuffer-force-complete-and-exit)
> >
> > Why?
> > Needing to do that is something new.  The binding has
> > been `minibuffer-complete-and-exit' since Day One.
> 
> I tried to check the function bound to RET in the minibuffer,
> but in Emacs 29 typing 'C-h f C-h k RET' raises an error:

Can't help you with Emacs 29, sorry.  Doesn't exist for me.

To see what RET is bound to in the map you cited you can
use `M-x describe-keymap minibuffer-local-must-match-map'.

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

[Eli Zaretskii]

> Cc: "60252@debbugs.gnu.org" <60252@debbugs.gnu.org>
> From: Drew Adams <drew.adams@oracle.com>
> Date: Thu, 22 Dec 2022 23:25:05 +0000
> 
> > I suggest
> > 
> > (define-key minibuffer-local-must-match-map (kbd "RET") #'minibuffer-
> > force-complete-and-exit)
> 
> Why?
> 
> Needing to do that is something new.  The binding has
> been `minibuffer-complete-and-exit' since Day One.

It still does, so I'm not sure what is your point here.

Did you follow this discussion from the beginning and understand what
are the main issues being discussed here?

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

[Drew Adams]

> > > I suggest
> > > (define-key minibuffer-local-must-match-map
> > >   (kbd "RET") #'minibuffer-force-complete-and-exit)
> >
> > Why?
> > Needing to do that is something new.  The binding has
> > been `minibuffer-complete-and-exit' since Day One.
> 
> It still does, so I'm not sure what is your point here.

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.

I'm not sure what your point is here.

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

[Eli Zaretskii]

> 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 16:47:19 +0000
> 
> > > > I suggest
> > > > (define-key minibuffer-local-must-match-map
> > > >   (kbd "RET") #'minibuffer-force-complete-and-exit)
> > >
> > > Why?
> > > Needing to do that is something new.  The binding has
> > > been `minibuffer-complete-and-exit' since Day One.
> > 
> > It still does, so I'm not sure what is your point here.
> 
> 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.
> 
> I'm not sure what your point is here.

The point is that the behavior of minibuffer-complete-and-exit has
changed.  This is what this discussion is about.

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

[Drew Adams]

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

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

[Eli Zaretskii]

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

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

[Eli Zaretskii]

> Cc: 60252@debbugs.gnu.org
> Date: Thu, 22 Dec 2022 21:32:50 +0000
> From: Gregory Heytings <gregory@heytings.org>
> 
> I suggest
> 
> (define-key minibuffer-local-must-match-map (kbd "RET") #'minibuffer-force-complete-and-exit)

I think this can lead to many false positives.  The "ask for
confirmation" behavior is better, in that it prevents inadvertent
errors that are annoying to fix.

People who prevent speed, and are sure they will never be tripped by
the above, can always make the above customization in their init
files.  But there's no need to force this on everyone.

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

[Gregory Heytings]

>> I suggest
>>
>> (define-key minibuffer-local-must-match-map (kbd "RET") #'minibuffer-force-complete-and-exit)
>
> People who prefer speed, and are sure they will never be tripped by the 
> above, can always make the above customization in their init files. 
> But there's no need to force this on everyone.
>

Of course I did not suggest to force this on everyone, it was a suggestion 
for Martin who asked "some way to get the old behavior back".

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

[Eli Zaretskii]

> Date: Fri, 23 Dec 2022 11:21:58 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: rudalics@gmx.at, 60252@debbugs.gnu.org
> 
> >> I suggest
> >>
> >> (define-key minibuffer-local-must-match-map (kbd "RET") #'minibuffer-force-complete-and-exit)
> >
> > People who prefer speed, and are sure they will never be tripped by the 
> > above, can always make the above customization in their init files. 
> > But there's no need to force this on everyone.
> >
> 
> Of course I did not suggest to force this on everyone, it was a suggestion 
> for Martin who asked "some way to get the old behavior back".

I'm glad we agree here.

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

[martin rudalics]

 > I suggest
 >
 > (define-key minibuffer-local-must-match-map (kbd "RET") #'minibuffer-force-complete-and-exit)

Thanks, Gregory.  That would fix the use case I described but the cure
is much worse than the disease: Whenever I'd wanted to run some sort of
M-x foo I would get a pause, have the string [Sole Completion] appear in
the minibuffer and only then get foo executed.

Here I added the old specification to my changes to stash and am happily
done.  I would have preferred to see changes like this announced in NEWS
(or at least a short remark in the commit) so I would have spent less
time to find out what caused it, but if it's just a bug that had to be
fixed routinely, there's probably no need for that.

Thanks again, martin

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

[Gregory Heytings]

>> (define-key minibuffer-local-must-match-map (kbd "RET") #'minibuffer-force-complete-and-exit)
>
> Thanks, Gregory.  That would fix the use case I described but the cure 
> is much worse than the disease: Whenever I'd wanted to run some sort of 
> M-x foo I would get a pause, have the string [Sole Completion] appear in 
> the minibuffer and only then get foo executed.
>

You're welcome!  You can change that by customizing 
minibuffer-message-timeout and/or completion-show-inline-help.

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

[martin rudalics]

 > You can change that by customizing minibuffer-message-timeout

That's probably not really what I would want - I'd lose the ability to
see asynchronous messages while the minibuffer is active.  Right?

 > and/or completion-show-inline-help.

This might be better but apparently doesn't even have a manual entry.
I'm afraid all this is way above my head.

martin

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

[Eli Zaretskii]

> Cc: 60252@debbugs.gnu.org
> Date: Fri, 23 Dec 2022 09:33:05 +0100
> From: martin rudalics <rudalics@gmx.at>
> 
> I would have preferred to see changes like this announced in NEWS

Now done.

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

[martin rudalics]

 >> I would have preferred to see changes like this announced in NEWS
 >
 > Now done.

Thanks.  Closing this bug.

martin