GNU bug report logs - #72787
31.0.50; Invalid describe-function completion candidates

Previous Next

To reply to this bug, email your comments to 72787 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eshel Yaron <me <at> eshelyaron.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Invalid describe-function completion candidates
Date: Sat, 24 Aug 2024 12:54:40 +0200

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

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: bug-gnu-emacs <at> gnu.org, 72787 <at> debbugs.gnu.org,
 Eshel Yaron <me <at> eshelyaron.com>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#72787: 31.0.50;
 Invalid describe-function completion candidates
Date: Sat, 24 Aug 2024 11:15:44 +0000

"Eshel Yaron via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <bug-gnu-emacs <at> 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

Message #14 received at 72787 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text
 editors" <bug-gnu-emacs <at> gnu.org>
Cc: Pip Cet <pipcet <at> protonmail.com>, 72787 <at> debbugs.gnu.org, me <at> eshelyaron.com,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#72787: 31.0.50; Invalid describe-function completion
 candidates
Date: Mon, 26 Aug 2024 03:41:26 +0200

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

Message #20 received at 72787 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 72787 <at> debbugs.gnu.org, me <at> eshelyaron.com, Pip Cet <pipcet <at> protonmail.com>
Subject: Re: bug#72787: 31.0.50; Invalid describe-function completion
 candidates
Date: Sun, 25 Aug 2024 22:37:01 -0400

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

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Cc: Pip Cet <pipcet <at> protonmail.com>, 72787 <at> debbugs.gnu.org, me <at> eshelyaron.com,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#72787: 31.0.50; Invalid describe-function completion
 candidates
Date: Tue, 27 Aug 2024 01:57:53 +0200

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> 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.

Message #31 received at 72787-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: michael_heerdegen <at> web.de, 72787-done <at> debbugs.gnu.org, me <at> eshelyaron.com,
 pipcet <at> protonmail.com
Subject: Re: bug#72787: 31.0.50;
 Invalid describe-function completion candidates
Date: Sat, 31 Aug 2024 12:54:19 +0300

> Cc: 72787 <at> debbugs.gnu.org, me <at> eshelyaron.com, Pip Cet <pipcet <at> 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 <at> 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.

Message #34 received at 72787-done <at> debbugs.gnu.org (full text, mbox):

From: Eshel Yaron <me <at> eshelyaron.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, pipcet <at> protonmail.com, 72787-done <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#72787: 31.0.50; Invalid describe-function completion
 candidates
Date: Sun, 01 Sep 2024 19:41:47 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: 72787 <at> debbugs.gnu.org, me <at> eshelyaron.com, Pip Cet <pipcet <at> 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 <at> 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

Message #37 received at 72787 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: michael_heerdegen <at> web.de, pipcet <at> protonmail.com, 72787 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#72787: 31.0.50; Invalid describe-function completion
 candidates
Date: Sun, 01 Sep 2024 21:00:23 +0300

reopen 72787
thanks

> From: Eshel Yaron <me <at> eshelyaron.com>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  michael_heerdegen <at> web.de,
>   72787-done <at> debbugs.gnu.org,  pipcet <at> 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.

Message #46 received at 72787 <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, pipcet <at> protonmail.com,
 Eshel Yaron <me <at> eshelyaron.com>, 72787 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#72787: 31.0.50; Invalid describe-function completion
 candidates
Date: Thu, 10 Oct 2024 06:56:58 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Eshel Yaron <me <at> eshelyaron.com>
>> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  michael_heerdegen <at> web.de,
>>   72787-done <at> debbugs.gnu.org,  pipcet <at> 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.

Is it possible to revert this change on master as well until a new
working patch is available?  IIUC, Stefan noted upthread:

  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.

The current behavior is somewhat annoying.

Best, Arash

Message #49 received at 72787 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Arash Esbati <arash <at> gnu.org>, monnier <at> iro.umontreal.ca
Cc: michael_heerdegen <at> web.de, pipcet <at> protonmail.com, me <at> eshelyaron.com,
 72787 <at> debbugs.gnu.org
Subject: Re: bug#72787: 31.0.50; Invalid describe-function completion
 candidates
Date: Thu, 10 Oct 2024 09:34:12 +0300

> From: Arash Esbati <arash <at> gnu.org>
> Cc: Eshel Yaron <me <at> eshelyaron.com>,  michael_heerdegen <at> web.de,
>   pipcet <at> protonmail.com,  72787 <at> debbugs.gnu.org,  monnier <at> iro.umontreal.ca
> Date: Thu, 10 Oct 2024 06:56:58 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Eshel Yaron <me <at> eshelyaron.com>
> >> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  michael_heerdegen <at> web.de,
> >>   72787-done <at> debbugs.gnu.org,  pipcet <at> 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.
> 
> Is it possible to revert this change on master as well until a new
> working patch is available?  IIUC, Stefan noted upthread:
> 
>   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.
> 
> The current behavior is somewhat annoying.

AFAIU, Stefan later explained that this is a feature, but maybe I
misunderstood him.  See

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73473#16

Stefan?

Message #52 received at 72787 <at> debbugs.gnu.org (full text, mbox):

From: Eshel Yaron <me <at> eshelyaron.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, pipcet <at> protonmail.com,
 Arash Esbati <arash <at> gnu.org>, 72787 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#72787: 31.0.50; Invalid describe-function completion
 candidates
Date: Fri, 11 Oct 2024 08:34:04 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Arash Esbati <arash <at> gnu.org>
>> Cc: Eshel Yaron <me <at> eshelyaron.com>,  michael_heerdegen <at> web.de,
>>   pipcet <at> protonmail.com,  72787 <at> debbugs.gnu.org,  monnier <at> iro.umontreal.ca
>> Date: Thu, 10 Oct 2024 06:56:58 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> From: Eshel Yaron <me <at> eshelyaron.com>
>> >> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  michael_heerdegen <at> web.de,
>> >>   72787-done <at> debbugs.gnu.org,  pipcet <at> 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.
>> 
>> Is it possible to revert this change on master as well until a new
>> working patch is available?  IIUC, Stefan noted upthread:
>> 
>>   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.
>> 
>> The current behavior is somewhat annoying.
>
> AFAIU, Stefan later explained that this is a feature, but maybe I
> misunderstood him.  See
>
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73473#16

AFAIU, the feature here would be loading library foo just in time for
you to get help about symbol foo-bar.  But the way this feature is
currently implemented is by including incorrect completion candidates.
That's not a feature, that's an implementation artifact, which
unfortunately happens to create an unpleasant UX :/

So I suggest doing one of the following:

- implement the feature differently, without this side-effect; or
- make it opt-in; or at least
- allow users to opt-out.


Best,

Eshel

Message #55 received at 72787 <at> debbugs.gnu.org (full text, mbox):

From: Eshel Yaron <me <at> eshelyaron.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, pipcet <at> protonmail.com,
 Arash Esbati <arash <at> gnu.org>, 72787 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#72787: 31.0.50; Invalid describe-function completion
 candidates
Date: Fri, 11 Oct 2024 11:18:49 +0200

Eshel Yaron <me <at> eshelyaron.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Arash Esbati <arash <at> gnu.org>
>>> 
>>> Is it possible to revert this change on master as well until a new
>>> working patch is available?  IIUC, Stefan noted upthread:
>>> 
>>>   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.
>>> 
>>> The current behavior is somewhat annoying.
>>
>> AFAIU, Stefan later explained that this is a feature, but maybe I
>> misunderstood him.  See
>>
>>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73473#16
>
> AFAIU, the feature here would be loading library foo just in time for
> you to get help about symbol foo-bar.  But the way this feature is
> currently implemented is by including incorrect completion candidates.
> That's not a feature, that's an implementation artifact, which
> unfortunately happens to create an unpleasant UX :/
>
> So I suggest doing one of the following:
>
> - implement the feature differently, without this side-effect; or
> - make it opt-in; or at least
> - allow users to opt-out.

Correction: I forgot that there's already a way to opt-out, by setting
help-enable-completion-autoload to nil.


Cheers,

Eshel

Message #58 received at 72787 <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: michael_heerdegen <at> web.de, pipcet <at> protonmail.com,
 Eli Zaretskii <eliz <at> gnu.org>, 72787 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#72787: 31.0.50; Invalid describe-function completion
 candidates
Date: Fri, 11 Oct 2024 16:22:23 +0200

[Message part 1 (text/plain, inline)]

Eshel Yaron <me <at> eshelyaron.com> writes:

>> AFAIU, the feature here would be loading library foo just in time for
>> you to get help about symbol foo-bar.  But the way this feature is
>> currently implemented is by including incorrect completion candidates.
>> That's not a feature, that's an implementation artifact, which
>> unfortunately happens to create an unpleasant UX :/

Thanks for your response.  For me, this is what I see with

  • emacs Q
  • (setq completions-format 'vertical)
  • C-h v TAB

[Emacs-Q.png (image/png, inline)]

[Message part 3 (text/plain, inline)]

This is what I see when I do `package-initialize'; I have dash.el
installed as a dependency:

[Emacs-Q-package.png (image/png, inline)]

[Message part 5 (text/plain, inline)]

>> So I suggest doing one of the following:
>>
>> - implement the feature differently, without this side-effect; or

From the second image above, I'd say that the feature isn't working
correctly.

> Correction: I forgot that there's already a way to opt-out, by setting
> help-enable-completion-autoload to nil.

This is what I see after setting `help-enable-completion-autoload' to
nil:

[Emacs-Q-package-h-e-c-a-nil.png (image/png, inline)]

[Message part 7 (text/plain, inline)]

Thanks for the pointer, I've set the variable to nil for now.

Best, Arash

Message #61 received at 72787 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Arash Esbati <arash <at> gnu.org>
Cc: michael_heerdegen <at> web.de, Eli Zaretskii <eliz <at> gnu.org>,
 72787 <at> debbugs.gnu.org, Eshel Yaron <me <at> eshelyaron.com>, pipcet <at> protonmail.com
Subject: Re: bug#72787: 31.0.50; Invalid describe-function completion
 candidates
Date: Fri, 11 Oct 2024 18:22:59 -0400

>>> AFAIU, the feature here would be loading library foo just in time for
>>> you to get help about symbol foo-bar.

Actually, it's not so much for the case where you know you want to see
`foo-bar` (which should be handled by `help-enable-symbol-autoload`
already) but also to let you discover that there might be a `foo-bar`
because there's a `foo-`.

>>> So I suggest doing one of the following:
>>> - implement the feature differently, without this side-effect; or

I'm all for it but I don't know what that would look like.

> From the second image above, I'd say that the feature isn't working
> correctly.

Could you clarify which part of the picture make you think so?
[ Also, does (featurep 'dash) return nil or t before you perform that
  completion?  ]
[ Also did you get this with an Emacs which includes:

    commit 8683d64cc571500347a16e7cb7d144d723250489
    Author: Stefan Monnier <monnier <at> iro.umontreal.ca>
    Date:   Thu Oct 3 10:25:13 2024 -0400
    
        (help--symbol-completion-table): Try and fix bug#73473
        
        * lisp/help-fns.el (help--symbol-completion-table): Be more
        careful with `help-enable-completion-autoload` so we don't load
        a package in cases where we already know it won't impact the result.

]

> This is what I see after setting `help-enable-completion-autoload' to nil:
[...]
> Thanks for the pointer, I've set the variable to nil for now.

Sorry for not mentioning it earlier, I stupidly assumed you were aware
of that variable.


        Stefan

Message #64 received at 72787 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: 72787 <at> debbugs.gnu.org
Subject: Re: bug#72787: 31.0.50; Invalid describe-function completion
 candidates
Date: Fri, 11 Oct 2024 19:34:07 -0400

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

I just pushed a fix to `master`.  Now you do get a *Completions* buffer
again (with more entries, tho, because
`help-enable-completions-autoload` loaded the `string-edit` package).


        Stefan

Message #67 received at 72787 <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: michael_heerdegen <at> web.de, Eli Zaretskii <eliz <at> gnu.org>,
 72787 <at> debbugs.gnu.org, Eshel Yaron <me <at> eshelyaron.com>, pipcet <at> protonmail.com
Subject: Re: bug#72787: 31.0.50; Invalid describe-function completion
 candidates
Date: Sat, 12 Oct 2024 11:41:31 +0200

[Message part 1 (text/plain, inline)]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Could you clarify which part of the picture make you think so?
> [ Also, does (featurep 'dash) return nil or t before you perform that
>   completion?  ]

I do:

• emacs -Q
• Eval:
    (progn
      (setq completions-format 'vertical)
      (package-initialize)
      (featurep 'dash))
  which returns nil
• 'C-h v TAB' and see this:

[Emacs-Q-package.png (image/png, inline)]

[Message part 3 (text/plain, inline)]

Take for example "-keep".  I do 'C-h v -keep RET' and get:

  -keep is void as a variable.

  Not documented as a variable.

Now I eval (require 'dash), do 'C-h v -keep RET' again and get:

  -keep is void as a variable.

  Not documented as a variable.

whereas 'C-h f -keep' returns:

  -keep is a native-comp-function in ‘dash.el’.

  (-keep FN LIST)

  Return a new list of the non-nil results of applying FN to each item in LIST.
  Like ‘-filter’, but returns the non-nil results of FN instead of
  the corresponding elements of LIST.

  Its anaphoric counterpart is ‘--keep’.

In summary, I see a void variable in the list of completions where the
function is defined.  Also, when I do 'emacs -Q' followed directly with
'C-h f TAB', I see this:

[Emacs-Q-funcs.png (image/png, inline)]

[Message part 5 (text/plain, inline)]

The (setf ...) part doesn't look right to me.

> [ Also did you get this with an Emacs which includes:
>
>     commit 8683d64cc571500347a16e7cb7d144d723250489
>     Author: Stefan Monnier <monnier <at> iro.umontreal.ca>
>     Date:   Thu Oct 3 10:25:13 2024 -0400
> ]

$ git show 8683d64cc571500347a16e7cb7d144d723250489
commit 8683d64cc571500347a16e7cb7d144d723250489
Author: Stefan Monnier <monnier <at> iro.umontreal.ca>
Date:   Thu Oct 3 10:25:13 2024 -0400

    (help--symbol-completion-table): Try and fix bug#73473

I'm runnig Emacs from master (ff4de9ef) on macOS.

> Sorry for not mentioning it earlier, I stupidly assumed you were aware
> of that variable.

I'm sorry I didn't investigate enough to find out about that variable
myself.

Best, Arash

Message #70 received at 72787 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Arash Esbati <arash <at> gnu.org>
Cc: michael_heerdegen <at> web.de, Eli Zaretskii <eliz <at> gnu.org>,
 72787 <at> debbugs.gnu.org, Eshel Yaron <me <at> eshelyaron.com>, pipcet <at> protonmail.com
Subject: Re: bug#72787: 31.0.50; Invalid describe-function completion
 candidates
Date: Sat, 12 Oct 2024 20:47:35 -0400

> In summary, I see a void variable in the list of completions where the
> function is defined.

Right, indeed this mechanism doesn't distinguish between variables and
functions.  It is intended for real namespace prefixes and presumes
these will be populated by both vars and funs, and that fails with
packages that don't obey the usual namespace prefixing rules.

We should make this mechanism more strict in this respect.
I see in `dash-autoloads.el` we end up using:

    (register-definition-prefixes "dash" '("!cdr" "!cons" "--" "->" "-a" "-butlast" "-c" "-d" "-e" "-f" "-gr" "-i" "-juxt" "-keep" "-l" "-m" "-no" "-o" "-p" "-r" "-s" "-t" "-u" "-value-to-list" "-when-let" "-zip" "dash-"))

It would be better to bail if our guessed set of prefixes is too large,
since it's usually a sign that our heuristic just failed, as here.

> Also, when I do 'emacs -Q' followed directly with
> 'C-h f TAB', I see this:
>
> The (setf ...) part doesn't look right to me.

These look correct to me, they're setter functions.


        Stefan

Message #73 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eshel Yaron <me <at> eshelyaron.com>
To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Cc: pipcet <at> protonmail.com, michael_heerdegen <at> web.de,
 Arash Esbati <arash <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 72787 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#72787: 31.0.50; Invalid describe-function completion
 candidates
Date: Sun, 13 Oct 2024 09:35:04 +0200

Hi Stefan,

Stefan Monnier writes:

>>>> AFAIU, the feature here would be loading library foo just in time for
>>>> you to get help about symbol foo-bar.
>
> Actually, it's not so much for the case where you know you want to see
> `foo-bar` (which should be handled by `help-enable-symbol-autoload`
> already) but also to let you discover that there might be a `foo-bar`
> because there's a `foo-`.

I see, so this is meant as a hint that should aid with discoverability.
Perhaps annotating these prefix candidates could make that more obvious:
I'm not sure that seeing "foo-" in *Completions* immediately suggests
"try to complete this prefix to see more candidates".

>>>> So I suggest doing one of the following:
>>>> - implement the feature differently, without this side-effect; or
>
> I'm all for it but I don't know what that would look like.

Personally I don't see this use case as important enough to break the
invariant that completion candidates are valid inputs, so I'd go a
different route.  The ability to load possibly-relevant libraries from
within the minibuffer is great, but I think that providing a command
that does that on demand would provide the same benefits.  Basically,
you would press a key when you want to check if some unloaded maybe
library defines something relevant.  Such a command could take into
account the current minibuffer input, so it can be as efficient as the
current facility. I can share a prototype if that sounds intriguing.


Best,

Eshel

Message #79 received at 72787 <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: michael_heerdegen <at> web.de, Eli Zaretskii <eliz <at> gnu.org>,
 72787 <at> debbugs.gnu.org, Eshel Yaron <me <at> eshelyaron.com>, pipcet <at> protonmail.com
Subject: Re: bug#72787: 31.0.50; Invalid describe-function completion
 candidates
Date: Mon, 14 Oct 2024 21:23:17 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Right, indeed this mechanism doesn't distinguish between variables and
> functions.

Thanks, this was a source of confusion, at least for me.

> It would be better to bail if our guessed set of prefixes is too
> large, since it's usually a sign that our heuristic just failed, as
> here.

That sounds like a good approach.

> These look correct to me, they're setter functions.

Ok, but I confess that I'd expect a symbol only here:

,----[ C-h f (setf seq-elt) RET ]
| \(setf\ seq-elt\) is a byte-code-function in ‘seq.el’.
| 
| (\(setf\ seq-elt\) ARG0 ARG &rest ARGS)
| 
| Not documented.
| 
| 
| This is a generic function.
| 
| Implementations:
| 
| (\(setf\ seq-elt\) STORE (SEQUENCE cons) N) in ‘seq.el’.
| 
| Undocumented
| 
| (\(setf\ seq-elt\) STORE (SEQUENCE array) N) in ‘seq.el’.
| 
| Undocumented
| 
`----

Best, Arash

Message #82 received at 72787 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Arash Esbati <arash <at> gnu.org>
Cc: michael_heerdegen <at> web.de, Eli Zaretskii <eliz <at> gnu.org>,
 72787 <at> debbugs.gnu.org, Eshel Yaron <me <at> eshelyaron.com>, pipcet <at> protonmail.com
Subject: Re: bug#72787: 31.0.50; Invalid describe-function completion
 candidates
Date: Mon, 14 Oct 2024 17:39:13 -0400

>> These look correct to me, they're setter functions.
>
> Ok, but I confess that I'd expect a symbol only here:

They are symbols:

> ,----[ C-h f (setf seq-elt) RET ]
> | \(setf\ seq-elt\) is a byte-code-function in ‘seq.el’.

See those backslashes?
It is the symbol returned by (intern "(setf seq-elt)").

In Common Lisp, you can define those functions for example with

    (defun (setf my-foo) (...) ...)

and ELisp supports that to some extent as well, tho currently
not for `defun`.


        Stefan

Message #85 received at 72787 <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: michael_heerdegen <at> web.de, Eli Zaretskii <eliz <at> gnu.org>,
 72787 <at> debbugs.gnu.org, Eshel Yaron <me <at> eshelyaron.com>, pipcet <at> protonmail.com
Subject: Re: bug#72787: 31.0.50; Invalid describe-function completion
 candidates
Date: Wed, 16 Oct 2024 22:31:40 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> In Common Lisp, you can define those functions for example with
>
>     (defun (setf my-foo) (...) ...)
>
> and ELisp supports that to some extent as well, tho currently
> not for `defun`.

Thanks for the clarification.

Best, Arash

Message #88 received at 72787 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: michael_heerdegen <at> web.de, pipcet <at> protonmail.com,
 Arash Esbati <arash <at> gnu.org>, 72787 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#72787: 31.0.50; Invalid describe-function completion
 candidates
Date: Thu, 17 Oct 2024 13:03:30 -0400

>> Actually, it's not so much for the case where you know you want to see
>> `foo-bar` (which should be handled by `help-enable-symbol-autoload`
>> already) but also to let you discover that there might be a `foo-bar`
>> because there's a `foo-`.
>
> I see, so this is meant as a hint that should aid with discoverability.

Yes.  Sometimes that works via *Completions* (i.e. it requires the user
to see the `foo-` entry and understand that it means there's something
with this prefix), but sometimes it works without it, e.g. when you do
`C-h f trac-ch TAB` which completes to `track-changes-` after which
the next TAB will show you the possible completions.

> Perhaps annotating these prefix candidates could make that more obvious:
> I'm not sure that seeing "foo-" in *Completions* immediately suggests
> "try to complete this prefix to see more candidates".

Agreed.

> Personally I don't see this use case as important enough to break the
> invariant that completion candidates are valid inputs, so I'd go a
> different route.  The ability to load possibly-relevant libraries from
> within the minibuffer is great, but I think that providing a command
> that does that on demand would provide the same benefits.  Basically,
> you would press a key when you want to check if some unloaded maybe
> library defines something relevant.  Such a command could take into
> account the current minibuffer input, so it can be as efficient as the
> current facility. I can share a prototype if that sounds intriguing.

The intention of the current behavior is to be a bit more transparent
and try to approximate the illusion of having `C-h o` (I personally
never use `C-h v` of `C-h f` any more) give information about any
function/variable defined in any of the installed packages, rather than
only in the currently loaded set of files.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.