bug#72787: 31.0.50; Invalid describe-function completion candidates

bug#72787: 31.0.50; Invalid describe-function completion candidates

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

Hi,

I've stumbled upon an issue with C-h f completions, both on the release
branch and on the master branch:

1. emacs -Q
2. C-h f string-edit- TAB

In Emacs 29, this pops up the *Completions* buffer, with 3 completion
candidates, string-edit-{abort,done,mode}.  That's the expected
behavior, because "string-edit-" is not itself a valid candidate.

However, in the release and master branches I get a minibuffer message
saying "Complete, but not unique".  This is incorrect, because the input
is not complete.  Another TAB pops up the *Completions* buffer, which is
now showing 4 candidates: the expected 3 plus "string-edit-" itself.
Typing RET exits the minibuffer without asking for confirmation, and
yields an error: "Symbol’s function definition is void: string-edit-".

So it seems like "string-edit-" is being considered as a valid
completion candidate, while it shouldn't be.


Thanks,

Eshel

bug#72787: 31.0.50; Invalid describe-function completion candidates

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

"Eshel Yaron via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <bug-gnu-emacs@gnu.org> writes:

> I've stumbled upon an issue with C-h f completions, both on the release
> branch and on the master branch:
>
> 1. emacs -Q
> 2. C-h f string-edit- TAB
>
> In Emacs 29, this pops up the *Completions* buffer, with 3 completion
> candidates, string-edit-{abort,done,mode}.  That's the expected
> behavior, because "string-edit-" is not itself a valid candidate.
>
> However, in the release and master branches I get a minibuffer message
> saying "Complete, but not unique".  This is incorrect, because the input
> is not complete.  Another TAB pops up the *Completions* buffer, which is
> now showing 4 candidates: the expected 3 plus "string-edit-" itself.
> Typing RET exits the minibuffer without asking for confirmation, and
> yields an error: "Symbol’s function definition is void: string-edit-".
>
> So it seems like "string-edit-" is being considered as a valid
> completion candidate, while it shouldn't be.

This appears to be caused by commit
45ae4de0e7ce99c88c62f940f605bca693b8e33f:

* lisp/help-fns.el (help-definition-prefixes): Don't delete the hashtable

Pip

bug#72787: 31.0.50; Invalid describe-function completion candidates

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

Hello,

Stefan's commit indeed seems related.  Stefan, could you maybe
have a look please?


Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> > 1. emacs -Q
> > 2. C-h f string-edit- TAB
> >
> > In Emacs 29, this pops up the *Completions* buffer, with 3 completion
> > candidates, string-edit-{abort,done,mode}.  That's the expected
> > behavior, because "string-edit-" is not itself a valid candidate.
> >
> > However, in the release and master branches I get a minibuffer message
> > saying "Complete, but not unique".  This is incorrect, because the input
> > is not complete.  Another TAB pops up the *Completions* buffer, which is
> > now showing 4 candidates: the expected 3 plus "string-edit-" itself.
> > Typing RET exits the minibuffer without asking for confirmation, and
> > yields an error: "Symbol’s function definition is void: string-edit-".
> >
> > So it seems like "string-edit-" is being considered as a valid
> > completion candidate, while it shouldn't be.
>
> This appears to be caused by commit
> 45ae4de0e7ce99c88c62f940f605bca693b8e33f:
>
> * lisp/help-fns.el (help-definition-prefixes): Don't delete the hashtable


TIA,

Michael.

bug#72787: 31.0.50; Invalid describe-function completion candidates

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

>> This appears to be caused by commit
>> 45ae4de0e7ce99c88c62f940f605bca693b8e33f:
>>
>> * lisp/help-fns.el (help-definition-prefixes): Don't delete the hashtable
> Stefan's commit indeed seems related.  Stefan, could you maybe
> have a look please?

I think this report makes it clear that
45ae4de0e7ce99c88c62f940f605bca693b8e33f should not have gone to
`emacs-30` but to `master`.  AFAIK it did not fix a regression or even
a user-visible bug.


        Stefan

bug#72787: 31.0.50; Invalid describe-function completion candidates

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

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

> > Stefan's commit indeed seems related.  Stefan, could you maybe
> > have a look please?
>
> I think this report makes it clear that
> 45ae4de0e7ce99c88c62f940f605bca693b8e33f should not have gone to
> `emacs-30` but to `master`.  AFAIK it did not fix a regression or even
> a user-visible bug.

So you will revert it on the release branch?

Michael.

bug#72787: 31.0.50; Invalid describe-function completion candidates

[Eli Zaretskii]

> Cc: 72787@debbugs.gnu.org, me@eshelyaron.com, Pip Cet <pipcet@protonmail.com>
> Date: Sun, 25 Aug 2024 22:37:01 -0400
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> >> This appears to be caused by commit
> >> 45ae4de0e7ce99c88c62f940f605bca693b8e33f:
> >>
> >> * lisp/help-fns.el (help-definition-prefixes): Don't delete the hashtable
> > Stefan's commit indeed seems related.  Stefan, could you maybe
> > have a look please?
> 
> I think this report makes it clear that
> 45ae4de0e7ce99c88c62f940f605bca693b8e33f should not have gone to
> `emacs-30` but to `master`.  AFAIK it did not fix a regression or even
> a user-visible bug.

Thanks, I've therefore reverted the above commit from the emacs-30
release branch, and I'm closing this bug.

bug#72787: 31.0.50; Invalid describe-function completion candidates

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

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: 72787@debbugs.gnu.org, me@eshelyaron.com, Pip Cet <pipcet@protonmail.com>
>> Date: Sun, 25 Aug 2024 22:37:01 -0400
>> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> >> This appears to be caused by commit
>> >> 45ae4de0e7ce99c88c62f940f605bca693b8e33f:
>> >>
>> >> * lisp/help-fns.el (help-definition-prefixes): Don't delete the hashtable
>> > Stefan's commit indeed seems related.  Stefan, could you maybe
>> > have a look please?
>> 
>> I think this report makes it clear that
>> 45ae4de0e7ce99c88c62f940f605bca693b8e33f should not have gone to
>> `emacs-30` but to `master`.  AFAIK it did not fix a regression or even
>> a user-visible bug.
>
> Thanks, I've therefore reverted the above commit from the emacs-30
> release branch, and I'm closing this bug.

Thanks, but the issue remains, so shouldn't the bug remain open as well?


Best,

Eshel

bug#72787: 31.0.50; Invalid describe-function completion candidates

[Eli Zaretskii]

reopen 72787
thanks

> From: Eshel Yaron <me@eshelyaron.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  michael_heerdegen@web.de,
>   72787-done@debbugs.gnu.org,  pipcet@protonmail.com
> Date: Sun, 01 Sep 2024 19:41:47 +0200
> 
> Thanks, but the issue remains, so shouldn't the bug remain open as well?

I reopened it.