GNU bug report logs - #79652
31.0.50; incorrect filtering in help--symbol-completion-table

Previous Next

To reply to this bug, email your comments to 79652 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: Lester Longley <lester <at> ieee.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; incorrect filtering in help--symbol-completion-table
Date: Sat, 18 Oct 2025 17:07:55 -0400

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

Hello,

I'm reporting a bug, with guidance from Daniel Mendler.
The original discussion is at
https://github.com/oantolin/orderless/issues/193

To readily demonstrate the issue, these packages need to be installed:

(1) https://elpa.gnu.org/packages/orderless.html
(2) https://elpa.gnu.org/packages/marginalia.html

Then:

$ emacs -Q

and execute the following additional setup manually:

(progn
  (dolist (path '("~/.emacs.d/elpa/marginalia-2.4"
"~/.emacs.d/elpa/orderless-1.5"))
    (add-to-list 'load-path path))

  (require 'marginalia)
  (marginalia-mode)

  (require 'orderless)
  (custom-set-variables
   '(completion-styles '(orderless basic))
   '(completion-category-overrides '(
      (command     (styles orderless basic))
      (symbol-help (styles orderless basic))
     ))
   )
)

The issue involves "completion", using this expression: describe-
&(C-h.[A-Z])

Background: "&(C-h.[A-Z])" is an "orderless-annotation" ("&..." is the
general form of the annotation).
More info.: https://github.com/oantolin/orderless#style-modifiers

The difference concerns completion using "M-x" vs. "C-h f" (or "C-h x").

With "M-x describe- &(C-h.[A-Z]) TAB", I get the expected results--commands
beginning with "describe-", which have key bindings of the form: C-h [A-Z].

[image: emacs-marginalia-orderless_M-x.png]

However, with "C-h f describe- &(C-h.[A-Z]) TAB", I see additional results,
unexpected (by me), i.e., additional functions which aren't bound to C-h
[A-Z]:

[image: emacs-marginalia-orderless_C-h_f.png]

FWIW, I get the same results using "C-h x" (`describe-command') as I do
with "C-h f" (`describe-function').

I don't know of a simple way to exclude marginalia from this puzzle, since
it's needed to add binding annotations with "C-h f".
However, I can use orderless *without* marginalia, using the default
suggest-key-bindings = t, and get the expected result from "M-x describe-
&(C-h.[A-Z]) TAB":

[image: emacs-orderless_M-x.png]
Daniel identified that the issue can be circumvented by customizing
`help-enable-completion-autoload' to nil (I have confirmed this workaround).

He further identified what he believes to be the root cause in
`help--symbol-completion-table'--see "BUG: or is not correct here ..."
embedded in the following function listing (near end):

(defun help--symbol-completion-table (string pred action)
  (if (eq action 'metadata)
      `(metadata
        ,@(when completions-detailed
            '((affixation-function .
help--symbol-completion-table-affixation)))
        (category . symbol-help))
    (when (and help-enable-completion-autoload
               (memq action '(nil t lambda)))
      (let ((prefixes (radix-tree-prefixes (help-definition-prefixes)
string)))
        ;; Don't load FOO.el during `test-completion' of `FOO-'.
        (unless (and (eq action 'lambda) (assoc string prefixes))
          (help--load-prefixes prefixes))))
    (let ((prefix-completions
           (and help-enable-completion-autoload
                (mapcar #'intern (all-completions string
definition-prefixes)))))
      (complete-with-action action obarray string
                            (if pred (lambda (sym)
                                       (or (funcall pred sym) ;; BUG: or is
not correct here, since it ignores the Orderless predicate!
                                           (memq sym
prefix-completions))))))))

Daniel further commented:

    "I'm unsure what a proper fix should look like. It's possible that the
issue cannot be resolved because the predicate might be intentionally
ignored.
    For autoloaded functions, there might not be enough information
available for the predicate to be satisfied.

    Maybe there is nothing we can do than to either disable
help-enable-completion-autoload completely ...,
    or make it less aggressively ignoring the predicate, or to live with
the additional unwanted candidates..."

Thanks,
Lester


In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.16.0) of 2025-09-25 built on penguin
Repository revision: e719f62a50645dc096ba899fb576168c2e3aa6d2
Repository branch: master
System Description: Debian GNU/Linux 12 (bookworm)

Configured using:
 'configure --with-pgtk 'CFLAGS=-g -O2
 -ffile-prefix-map=/tmp/emacs.git=. -fstack-protector-strong -Wformat
 -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  marginalia-mode: t
  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
  minibuffer-nonselected-mode: t
  minibuffer-regexp-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 compile comint ansi-osc ansi-color ring comp-run
bytecomp byte-compile comp-common rx emacsbug lisp-mnt 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
time-date subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils orderless marginalia
compat rmc iso-transl tooltip cconv eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win
pgtk-win term/common-win touch-screen pgtk-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 gtk pgtk
lcms2 multi-tty move-toolbar make-network-process tty-child-frames
native-compile emacs)

Memory information:
((conses 16 69797 11253) (symbols 48 7013 0) (strings 32 17533 1036)
 (string-bytes 1 564885) (vectors 16 10924)
 (vector-slots 8 153240 6968) (floats 8 31 103) (intervals 56 335 16)
 (buffers 1064 12))

[Message part 2 (text/html, inline)]

[emacs-marginalia-orderless_M-x.png (image/png, inline)]

[emacs-marginalia-orderless_C-h_f.png (image/png, inline)]

[emacs-orderless_M-x.png (image/png, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lester Longley <lester <at> ieee.org>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 79652 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#79652: 31.0.50;
 incorrect filtering in help--symbol-completion-table
Date: Sun, 19 Oct 2025 07:40:56 +0300

> Date: Sat, 18 Oct 2025 17:07:55 -0400
> From:  Lester Longley via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> I'm reporting a bug, with guidance from Daniel Mendler.
> The original discussion is at https://github.com/oantolin/orderless/issues/193
> 
> To readily demonstrate the issue, these packages need to be installed:
> 
> (1) https://elpa.gnu.org/packages/orderless.html
> (2) https://elpa.gnu.org/packages/marginalia.html
> 
> Then:
> 
> $ emacs -Q
> 
> and execute the following additional setup manually:
> 
> (progn
>   (dolist (path '("~/.emacs.d/elpa/marginalia-2.4" "~/.emacs.d/elpa/orderless-1.5"))
>     (add-to-list 'load-path path))
> 
>   (require 'marginalia)
>   (marginalia-mode)
> 
>   (require 'orderless)
>   (custom-set-variables
>    '(completion-styles '(orderless basic))
>    '(completion-category-overrides '(
>       (command     (styles orderless basic))
>       (symbol-help (styles orderless basic))
>      ))
>    )
> )
> 
> The issue involves "completion", using this expression: describe- &(C-h.[A-Z])
> 
> Background: "&(C-h.[A-Z])" is an "orderless-annotation" ("&..." is the general form of the annotation).
> More info.: https://github.com/oantolin/orderless#style-modifiers
> 
> The difference concerns completion using "M-x" vs. "C-h f" (or "C-h x").
> 
> With "M-x describe- &(C-h.[A-Z]) TAB", I get the expected results--commands beginning with "describe-",
> which have key bindings of the form: C-h [A-Z].
> 
> emacs-marginalia-orderless_M-x.png
> 
> However, with "C-h f describe- &(C-h.[A-Z]) TAB", I see additional results, unexpected (by me), i.e.,
> additional functions which aren't bound to C-h [A-Z]:
> 
> emacs-marginalia-orderless_C-h_f.png
> 
> FWIW, I get the same results using "C-h x" (`describe-command') as I do with "C-h f" (`describe-function').
> 
> I don't know of a simple way to exclude marginalia from this puzzle, since it's needed to add binding
> annotations with "C-h f".
> However, I can use orderless *without* marginalia, using the default suggest-key-bindings = t, and get the
> expected result from "M-x describe- &(C-h.[A-Z]) TAB":
> 
> emacs-orderless_M-x.png
> Daniel identified that the issue can be circumvented by customizing `help-enable-completion-autoload' to nil
> (I have confirmed this workaround).
> 
> He further identified what he believes to be the root cause in `help--symbol-completion-table'--see "BUG: or
> is not correct here ..." embedded in the following function listing (near end):
> 
> (defun help--symbol-completion-table (string pred action)
>   (if (eq action 'metadata)
>       `(metadata
>         ,@(when completions-detailed
>             '((affixation-function . help--symbol-completion-table-affixation)))
>         (category . symbol-help))
>     (when (and help-enable-completion-autoload
>                (memq action '(nil t lambda)))
>       (let ((prefixes (radix-tree-prefixes (help-definition-prefixes) string)))
>         ;; Don't load FOO.el during `test-completion' of `FOO-'.
>         (unless (and (eq action 'lambda) (assoc string prefixes))
>           (help--load-prefixes prefixes))))
>     (let ((prefix-completions
>            (and help-enable-completion-autoload
>                 (mapcar #'intern (all-completions string definition-prefixes)))))
>       (complete-with-action action obarray string
>                             (if pred (lambda (sym)
>                                        (or (funcall pred sym) ;; BUG: or is not correct here, since it ignores the Orderless
> predicate!
>                                            (memq sym prefix-completions))))))))
> 
> Daniel further commented:
> 
>     "I'm unsure what a proper fix should look like. It's possible that the issue cannot be resolved because the
> predicate might be intentionally ignored.
>     For autoloaded functions, there might not be enough information available for the predicate to be
> satisfied.
> 
>     Maybe there is nothing we can do than to either disable help-enable-completion-autoload completely ...,
>     or make it less aggressively ignoring the predicate, or to live with the additional unwanted candidates..."

Thanks, I added the relevant people to the discussion.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79652 <at> debbugs.gnu.org, Lester Longley <lester <at> ieee.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#79652: 31.0.50; incorrect filtering in
 help--symbol-completion-table
Date: Sun, 19 Oct 2025 16:50:34 +0200

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

>> Date: Sat, 18 Oct 2025 17:07:55 -0400
>> From:  Lester Longley via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> I'm reporting a bug, with guidance from Daniel Mendler.
>> The original discussion is at https://github.com/oantolin/orderless/issues/193
>> 
>> To readily demonstrate the issue, these packages need to be installed:
>> 
>> (1) https://elpa.gnu.org/packages/orderless.html
>> (2) https://elpa.gnu.org/packages/marginalia.html
>> 
>> Then:
>> 
>> $ emacs -Q
>> 
>> and execute the following additional setup manually:
>> 
>> (progn
>>   (dolist (path '("~/.emacs.d/elpa/marginalia-2.4" "~/.emacs.d/elpa/orderless-1.5"))
>>     (add-to-list 'load-path path))
>> 
>>   (require 'marginalia)
>>   (marginalia-mode)
>> 
>>   (require 'orderless)
>>   (custom-set-variables
>>    '(completion-styles '(orderless basic))
>>    '(completion-category-overrides '(
>>       (command     (styles orderless basic))
>>       (symbol-help (styles orderless basic))
>>      ))
>>    )
>> )
>> 
>> The issue involves "completion", using this expression: describe- &(C-h.[A-Z])
>> 
>> Background: "&(C-h.[A-Z])" is an "orderless-annotation" ("&..." is the general form of the annotation).
>> More info.: https://github.com/oantolin/orderless#style-modifiers
>> 
>> The difference concerns completion using "M-x" vs. "C-h f" (or "C-h x").
>> 
>> With "M-x describe- &(C-h.[A-Z]) TAB", I get the expected results--commands beginning with "describe-",
>> which have key bindings of the form: C-h [A-Z].
>> 
>> emacs-marginalia-orderless_M-x.png
>> 
>> However, with "C-h f describe- &(C-h.[A-Z]) TAB", I see additional results, unexpected (by me), i.e.,
>> additional functions which aren't bound to C-h [A-Z]:
>> 
>> emacs-marginalia-orderless_C-h_f.png
>> 
>> FWIW, I get the same results using "C-h x" (`describe-command') as I do with "C-h f" (`describe-function').
>> 
>> I don't know of a simple way to exclude marginalia from this puzzle, since it's needed to add binding
>> annotations with "C-h f".
>> However, I can use orderless *without* marginalia, using the default suggest-key-bindings = t, and get the
>> expected result from "M-x describe- &(C-h.[A-Z]) TAB":
>> 
>> emacs-orderless_M-x.png
>> Daniel identified that the issue can be circumvented by customizing `help-enable-completion-autoload' to nil
>> (I have confirmed this workaround).
>> 
>> He further identified what he believes to be the root cause in `help--symbol-completion-table'--see "BUG: or
>> is not correct here ..." embedded in the following function listing (near end):
>> 
>> (defun help--symbol-completion-table (string pred action)
>>   (if (eq action 'metadata)
>>       `(metadata
>>         ,@(when completions-detailed
>>             '((affixation-function . help--symbol-completion-table-affixation)))
>>         (category . symbol-help))
>>     (when (and help-enable-completion-autoload
>>                (memq action '(nil t lambda)))
>>       (let ((prefixes (radix-tree-prefixes (help-definition-prefixes) string)))
>>         ;; Don't load FOO.el during `test-completion' of `FOO-'.
>>         (unless (and (eq action 'lambda) (assoc string prefixes))
>>           (help--load-prefixes prefixes))))
>>     (let ((prefix-completions
>>            (and help-enable-completion-autoload
>>                 (mapcar #'intern (all-completions string definition-prefixes)))))
>>       (complete-with-action action obarray string
>>                             (if pred (lambda (sym)
>>                                        (or (funcall pred sym) ;; BUG: or is not correct here, since it ignores the Orderless
>> predicate!
>>                                            (memq sym prefix-completions))))))))
>> 
>> Daniel further commented:
>> 
>>     "I'm unsure what a proper fix should look like. It's possible that the issue cannot be resolved because the
>> predicate might be intentionally ignored.
>>     For autoloaded functions, there might not be enough information available for the predicate to be
>> satisfied.
>> 
>>     Maybe there is nothing we can do than to either disable help-enable-completion-autoload completely ...,
>>     or make it less aggressively ignoring the predicate, or to live with the additional unwanted candidates..."
>
> Thanks, I added the relevant people to the discussion.

Stefan, do you an idea how we could resolve the predicate issue? Also
I've discovered that the help autoloading leads to artificial
candidates. Starting from emacs -Q enter "C-h f describe ?". Then the
invalid symbol `describe-' appears in the completion list. I think I've
seen reports about this problem before.

Daniel

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>, monnier <at> iro.umontreal.ca
Cc: 79652 <at> debbugs.gnu.org, lester <at> ieee.org
Subject: Re: bug#79652: 31.0.50; incorrect filtering in
 help--symbol-completion-table
Date: Sat, 08 Nov 2025 12:51:28 +0200

Ping!  Stefan, can you please respond?

> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Cc: Lester Longley <lester <at> ieee.org>,  79652 <at> debbugs.gnu.org,  Stefan
>  Monnier <monnier <at> iro.umontreal.ca>
> Date: Sun, 19 Oct 2025 16:50:34 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Date: Sat, 18 Oct 2025 17:07:55 -0400
> >> From:  Lester Longley via "Bug reports for GNU Emacs,
> >>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >> 
> >> I'm reporting a bug, with guidance from Daniel Mendler.
> >> The original discussion is at https://github.com/oantolin/orderless/issues/193
> >> 
> >> To readily demonstrate the issue, these packages need to be installed:
> >> 
> >> (1) https://elpa.gnu.org/packages/orderless.html
> >> (2) https://elpa.gnu.org/packages/marginalia.html
> >> 
> >> Then:
> >> 
> >> $ emacs -Q
> >> 
> >> and execute the following additional setup manually:
> >> 
> >> (progn
> >>   (dolist (path '("~/.emacs.d/elpa/marginalia-2.4" "~/.emacs.d/elpa/orderless-1.5"))
> >>     (add-to-list 'load-path path))
> >> 
> >>   (require 'marginalia)
> >>   (marginalia-mode)
> >> 
> >>   (require 'orderless)
> >>   (custom-set-variables
> >>    '(completion-styles '(orderless basic))
> >>    '(completion-category-overrides '(
> >>       (command     (styles orderless basic))
> >>       (symbol-help (styles orderless basic))
> >>      ))
> >>    )
> >> )
> >> 
> >> The issue involves "completion", using this expression: describe- &(C-h.[A-Z])
> >> 
> >> Background: "&(C-h.[A-Z])" is an "orderless-annotation" ("&..." is the general form of the annotation).
> >> More info.: https://github.com/oantolin/orderless#style-modifiers
> >> 
> >> The difference concerns completion using "M-x" vs. "C-h f" (or "C-h x").
> >> 
> >> With "M-x describe- &(C-h.[A-Z]) TAB", I get the expected results--commands beginning with "describe-",
> >> which have key bindings of the form: C-h [A-Z].
> >> 
> >> emacs-marginalia-orderless_M-x.png
> >> 
> >> However, with "C-h f describe- &(C-h.[A-Z]) TAB", I see additional results, unexpected (by me), i.e.,
> >> additional functions which aren't bound to C-h [A-Z]:
> >> 
> >> emacs-marginalia-orderless_C-h_f.png
> >> 
> >> FWIW, I get the same results using "C-h x" (`describe-command') as I do with "C-h f" (`describe-function').
> >> 
> >> I don't know of a simple way to exclude marginalia from this puzzle, since it's needed to add binding
> >> annotations with "C-h f".
> >> However, I can use orderless *without* marginalia, using the default suggest-key-bindings = t, and get the
> >> expected result from "M-x describe- &(C-h.[A-Z]) TAB":
> >> 
> >> emacs-orderless_M-x.png
> >> Daniel identified that the issue can be circumvented by customizing `help-enable-completion-autoload' to nil
> >> (I have confirmed this workaround).
> >> 
> >> He further identified what he believes to be the root cause in `help--symbol-completion-table'--see "BUG: or
> >> is not correct here ..." embedded in the following function listing (near end):
> >> 
> >> (defun help--symbol-completion-table (string pred action)
> >>   (if (eq action 'metadata)
> >>       `(metadata
> >>         ,@(when completions-detailed
> >>             '((affixation-function . help--symbol-completion-table-affixation)))
> >>         (category . symbol-help))
> >>     (when (and help-enable-completion-autoload
> >>                (memq action '(nil t lambda)))
> >>       (let ((prefixes (radix-tree-prefixes (help-definition-prefixes) string)))
> >>         ;; Don't load FOO.el during `test-completion' of `FOO-'.
> >>         (unless (and (eq action 'lambda) (assoc string prefixes))
> >>           (help--load-prefixes prefixes))))
> >>     (let ((prefix-completions
> >>            (and help-enable-completion-autoload
> >>                 (mapcar #'intern (all-completions string definition-prefixes)))))
> >>       (complete-with-action action obarray string
> >>                             (if pred (lambda (sym)
> >>                                        (or (funcall pred sym) ;; BUG: or is not correct here, since it ignores the Orderless
> >> predicate!
> >>                                            (memq sym prefix-completions))))))))
> >> 
> >> Daniel further commented:
> >> 
> >>     "I'm unsure what a proper fix should look like. It's possible that the issue cannot be resolved because the
> >> predicate might be intentionally ignored.
> >>     For autoloaded functions, there might not be enough information available for the predicate to be
> >> satisfied.
> >> 
> >>     Maybe there is nothing we can do than to either disable help-enable-completion-autoload completely ...,
> >>     or make it less aggressively ignoring the predicate, or to live with the additional unwanted candidates..."
> >
> > Thanks, I added the relevant people to the discussion.
> 
> Stefan, do you an idea how we could resolve the predicate issue? Also
> I've discovered that the help autoloading leads to artificial
> candidates. Starting from emacs -Q enter "C-h f describe ?". Then the
> invalid symbol `describe-' appears in the completion list. I think I've
> seen reports about this problem before.
> 
> Daniel
> 

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lester Longley <lester <at> ieee.org>
Cc: 79652 <at> debbugs.gnu.org
Subject: Re: bug#79652: 31.0.50; incorrect filtering in
 help--symbol-completion-table
Date: Tue, 11 Nov 2025 11:59:34 -0500

[ Sorry for not replying earlier.  Thanks Eli for pinging me.  ]

> However, with "C-h f describe- &(C-h.[A-Z]) TAB", I see additional results,
> unexpected (by me), i.e., additional functions which aren't bound to C-h
> [A-Z]:
>
> [image: emacs-marginalia-orderless_C-h_f.png]

[...]

>       (complete-with-action action obarray string
>                             (if pred (lambda (sym)
>                                        (or (funcall pred sym) ;; BUG: or is
> not correct here, since it ignores the Orderless predicate!
>                                            (memq sym
> prefix-completions))))))))

That looks like the right place, indeed.
I see two different kinds of added elements:

A) Things like `describe-font-internal` and `describe-mode-local-bindings`:
   These are "clearly wrong".
B) Things like `describe-theme-`, where it's not nearly as clear: such
   elements are included to help you get to those functions whose name
   starts with `describe-theme-` but which haven't yet been loaded.
   It's possible that one of those functions is actually a command bound
   in the `C-h` keymap, so Emacs doesn't know yet whether to include it
   or not.

Sadly, currently, Emacs doesn't know that `describe-theme-` is a prefix
whereas `describe-font-internal` is not: the mechanism that fills the
`prefix-completions` variable above does not keep track of
that information.

Also, in order to be able to apply `pred` to those prefix-completions
(regardless if they're (A) or (B)), we'd have to load the corresponding
files.  In your example, this would be `mule-diag.el`, `mode-local.el`,
and `cus-theme.el` (plus all the files those files may `require`), which
might be tolerable, but if you had typed `d &C-h.[A-Z]` before hitting
TAB, you'd be looking at eagerly loading a significantly larger number
of packages, so it would be problematic to perform such loads in general.

Hmm...


        Stefan

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

From: Lester Longley <lester <at> ieee.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 79652 <at> debbugs.gnu.org
Subject: Re: bug#79652: 31.0.50;
 incorrect filtering in help--symbol-completion-table
Date: Wed, 12 Nov 2025 11:58:40 -0500

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

Hi Stefan,

(Looping Daniel back in ...)

Thanks for your comments.

I guess, for me at least, there will be times when I like having
`help-enable-completion-autoload' turned on, but other times when I'd
prefer that it be disabled.

It occurs to me that it could be useful to allow describe-function,
describe-command, etc.
to be dynamically controlled, say with a prefix argument (C-u),
to invert the `help-enable-completion-autoload' setting.
(I don't see that these commands currently use a prefix argument.)

I might experiment with that approach.

Regards,
Lester

On Tue, Nov 11, 2025 at 11:59 AM Stefan Monnier <monnier <at> iro.umontreal.ca>
wrote:
> [ Sorry for not replying earlier.  Thanks Eli for pinging me.  ]
>
> > However, with "C-h f describe- &(C-h.[A-Z]) TAB", I see additional
results,
> > unexpected (by me), i.e., additional functions which aren't bound to C-h
> > [A-Z]:
> >
> > [image: emacs-marginalia-orderless_C-h_f.png]
>
> [...]
>
> >       (complete-with-action action obarray string
> >                             (if pred (lambda (sym)
> >                                        (or (funcall pred sym) ;; BUG:
or is
> > not correct here, since it ignores the Orderless predicate!
> >                                            (memq sym
> > prefix-completions))))))))
>
> That looks like the right place, indeed.
> I see two different kinds of added elements:
>
> A) Things like `describe-font-internal` and
`describe-mode-local-bindings`:
>    These are "clearly wrong".
> B) Things like `describe-theme-`, where it's not nearly as clear: such
>    elements are included to help you get to those functions whose name
>    starts with `describe-theme-` but which haven't yet been loaded.
>    It's possible that one of those functions is actually a command bound
>    in the `C-h` keymap, so Emacs doesn't know yet whether to include it
>    or not.
>
> Sadly, currently, Emacs doesn't know that `describe-theme-` is a prefix
> whereas `describe-font-internal` is not: the mechanism that fills the
> `prefix-completions` variable above does not keep track of
> that information.
>
> Also, in order to be able to apply `pred` to those prefix-completions
> (regardless if they're (A) or (B)), we'd have to load the corresponding
> files.  In your example, this would be `mule-diag.el`, `mode-local.el`,
> and `cus-theme.el` (plus all the files those files may `require`), which
> might be tolerable, but if you had typed `d &C-h.[A-Z]` before hitting
> TAB, you'd be looking at eagerly loading a significantly larger number
> of packages, so it would be problematic to perform such loads in general.
>
> Hmm...
>
>
>         Stefan

[Message part 2 (text/html, inline)]

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lester Longley <lester <at> ieee.org>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 79652 <at> debbugs.gnu.org
Subject: Re: bug#79652: 31.0.50; incorrect filtering in
 help--symbol-completion-table
Date: Wed, 12 Nov 2025 16:14:44 -0500

> (Looping Daniel back in ...)

Thanks, sorry about that.

> I guess, for me at least, there will be times when I like having
> `help-enable-completion-autoload' turned on, but other times when I'd
> prefer that it be disabled.

Yes, that's the problem with those autoloaded completions.

> It occurs to me that it could be useful to allow describe-function,
> describe-command, etc.
> to be dynamically controlled, say with a prefix argument (C-u),
> to invert the `help-enable-completion-autoload' setting.
> (I don't see that these commands currently use a prefix argument.)

I can see that working for someone very aware of that subtlety, but my
impression is that it wouldn't be useful for most users.

Maybe we could add an annotation (e.g. saying "not loaded yet", to try
and explain what's going on) plus a way for the users to ask to hide
those for the current completion.


        Stefan

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

From: Lester Longley <lester <at> ieee.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 79652 <at> debbugs.gnu.org
Subject: Re: bug#79652: 31.0.50;
 incorrect filtering in help--symbol-completion-table
Date: Wed, 12 Nov 2025 17:50:52 -0500

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

On Wed, Nov 12, 2025 at 4:14 PM Stefan Monnier <monnier <at> iro.umontreal.ca>
wrote:
> > I guess, for me at least, there will be times when I like having
> > `help-enable-completion-autoload' turned on, but other times when I'd
> > prefer that it be disabled.
>
> Yes, that's the problem with those autoloaded completions.
>
> > It occurs to me that it could be useful to allow describe-function,
> > describe-command, etc.
> > to be dynamically controlled, say with a prefix argument (C-u),
> > to invert the `help-enable-completion-autoload' setting.
> > (I don't see that these commands currently use a prefix argument.)
>
> I can see that working for someone very aware of that subtlety, but my
> impression is that it wouldn't be useful for most users.

I can understand that :-) - it's just all that I could imagine doing myself.

> Maybe we could add an annotation (e.g. saying "not loaded yet", to try
> and explain what's going on) plus a way for the users to ask to hide
> those for the current completion.

I think that such an annotation would be quite informative & take away some
"mystery" in the completion process,
and even better to be able to hide those when they're not wanted.

Regards,
Lester

[Message part 2 (text/html, inline)]

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 79652 <at> debbugs.gnu.org, Lester Longley <lester <at> ieee.org>
Subject: Re: bug#79652: 31.0.50; incorrect filtering in
 help--symbol-completion-table
Date: Thu, 13 Nov 2025 00:52:47 +0100

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

>> (Looping Daniel back in ...)
>
> Thanks, sorry about that.
>
>> I guess, for me at least, there will be times when I like having
>> `help-enable-completion-autoload' turned on, but other times when I'd
>> prefer that it be disabled.
>
> Yes, that's the problem with those autoloaded completions.
>
>> It occurs to me that it could be useful to allow describe-function,
>> describe-command, etc.
>> to be dynamically controlled, say with a prefix argument (C-u),
>> to invert the `help-enable-completion-autoload' setting.
>> (I don't see that these commands currently use a prefix argument.)
>
> I can see that working for someone very aware of that subtlety, but my
> impression is that it wouldn't be useful for most users.
>
> Maybe we could add an annotation (e.g. saying "not loaded yet", to try
> and explain what's going on) plus a way for the users to ask to hide
> those for the current completion.

That's a good idea. I've added such annotations to Marginalia in commit:

https://github.com/minad/marginalia/commit/d986750342866f5a77ab96b69c641b805edba886

>         Stefan

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Lester Longley <lester <at> ieee.org>
Cc: 79652 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#79652: 31.0.50; incorrect filtering in
 help--symbol-completion-table
Date: Thu, 13 Nov 2025 00:55:18 +0100

Lester Longley <lester <at> ieee.org> writes:

> On Wed, Nov 12, 2025 at 4:14 PM Stefan Monnier <monnier <at> iro.umontreal.ca>
> wrote:
>> > I guess, for me at least, there will be times when I like having
>> > `help-enable-completion-autoload' turned on, but other times when I'd
>> > prefer that it be disabled.
>>
>> Yes, that's the problem with those autoloaded completions.
>>
>> > It occurs to me that it could be useful to allow describe-function,
>> > describe-command, etc.
>> > to be dynamically controlled, say with a prefix argument (C-u),
>> > to invert the `help-enable-completion-autoload' setting.
>> > (I don't see that these commands currently use a prefix argument.)
>>
>> I can see that working for someone very aware of that subtlety, but my
>> impression is that it wouldn't be useful for most users.
>
> I can understand that :-) - it's just all that I could imagine doing myself.
>
>> Maybe we could add an annotation (e.g. saying "not loaded yet", to try
>> and explain what's going on) plus a way for the users to ask to hide
>> those for the current completion.
>
> I think that such an annotation would be quite informative & take away some
> "mystery" in the completion process,
> and even better to be able to hide those when they're not wanted.

I have added such an annotation to Marginalia just now. But it will not
be possible to hide them if they are not wanted, in case you meant via
Orderless annotation filtering, since the Orderless completion predicate
gets circumvented if `help-enable-completion-autoload' is enabled. This
was the original reason for this bug report.

> Regards,
> Lester

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 79652 <at> debbugs.gnu.org, Lester Longley <lester <at> ieee.org>
Subject: Re: bug#79652: 31.0.50; incorrect filtering in
 help--symbol-completion-table
Date: Thu, 13 Nov 2025 05:45:20 -0500

> I have added such an annotation to Marginalia just now.

Thanks.  Hopefully Someone will get to add such a thing to Emacs itself
at some point, but in the mean time it makes this solution available.

> But it will not be possible to hide them if they are not wanted, in
> case you meant via Orderless annotation filtering, since the Orderless
> completion predicate gets circumvented if
> `help-enable-completion-autoload' is enabled. This was the original
> reason for this bug report.

The UI I was imagining was the user clicking somehow (right click menu?)
on those entries in *Completions*, causing the variable
`help-enable-completion-autoload` to be temporarily set to nil.

I don't have a clear idea how that would be implemented, and even less
how that could work with corfu/company/vertico/icomplete/...  🙁


        Stefan

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

From: Lester Longley <lester <at> ieee.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 79652 <at> debbugs.gnu.org
Subject: Re: bug#79652: 31.0.50;
 incorrect filtering in help--symbol-completion-table
Date: Thu, 13 Nov 2025 08:45:00 -0500

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

Hi Daniel, Stefan,

On Thu, Nov 13, 2025 at 5:45 AM Stefan Monnier <monnier <at> iro.umontreal.ca>
wrote:
>
> > I have added such an annotation to Marginalia just now.
>
> Thanks.  Hopefully Someone will get to add such a thing to Emacs itself
> at some point, but in the mean time it makes this solution available.

I tried out the updated Marginalia & that works well.
Thanks to Stefan for the idea and to Daniel for the (quick!) implementation.

> > But it will not be possible to hide them if they are not wanted, in
> > case you meant via Orderless annotation filtering, since the Orderless
> > completion predicate gets circumvented if
> > `help-enable-completion-autoload' is enabled. This was the original
> > reason for this bug report.
>
> The UI I was imagining was the user clicking somehow (right click menu?)
> on those entries in *Completions*, causing the variable
> `help-enable-completion-autoload` to be temporarily set to nil.
>
> I don't have a clear idea how that would be implemented, and even less
> how that could work with corfu/company/vertico/icomplete/...

Would it be possible (& make sense?) for
orderless-all-completions (→ orderless-filter →
help--symbol-completion-table) to temp. turn off
'help-enable-completion-autoload' ?

Regards,
Lester

[Message part 2 (text/html, inline)]

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

From: Lester Longley <lester <at> ieee.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 79652 <at> debbugs.gnu.org
Subject: Re: bug#79652: 31.0.50;
 incorrect filtering in help--symbol-completion-table
Date: Thu, 13 Nov 2025 09:14:32 -0500

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

Hello again,

On Thu, Nov 13, 2025 at 8:45 AM Lester Longley <lester <at> ieee.org> wrote:
> On Thu, Nov 13, 2025 at 5:45 AM Stefan Monnier <monnier <at> iro.umontreal.ca>
wrote:
> > > But it will not be possible to hide them if they are not wanted, in
> > > case you meant via Orderless annotation filtering, since the Orderless
> > > completion predicate gets circumvented if
> > > `help-enable-completion-autoload' is enabled. This was the original
> > > reason for this bug report.
> >
> > The UI I was imagining was the user clicking somehow (right click menu?)
> > on those entries in *Completions*, causing the variable
> > `help-enable-completion-autoload` to be temporarily set to nil.
> >
> > I don't have a clear idea how that would be implemented, and even less
> > how that could work with corfu/company/vertico/icomplete/...
>
> Would it be possible (& make sense?) for orderless-all-completions (→
orderless-filter → help--symbol-completion-table) to temp. turn off
'help-enable-completion-autoload' ?

I.e., when an orderless annotation is in use.

Though I suppose that's a bit hacky.

Going back to this point:

>> It occurs to me that it could be useful to allow describe-function,
>> describe-command, etc.
>> to be dynamically controlled, say with a prefix argument (C-u),
>> to invert the `help-enable-completion-autoload' setting.
>> (I don't see that these commands currently use a prefix argument.)
>
> I can see that working for someone very aware of that subtlety, but my
> impression is that it wouldn't be useful for most users.

... arguably, it's not *too* subtle, since the docstrings for
describe-function et al. mention `help-enable-completion-autoload'
specifically:

> describe-function is an autoloaded interactive native-comp-function in
‘help-fns.el’.
> ...
> Display the full documentation of FUNCTION (a symbol).
> When called from Lisp, FUNCTION may also be a function object.
>
> See the ‘help-enable-symbol-autoload’ variable for special handling of
autoloaded functions.

So, adding mention here (and implementation of course) of a prefix arg to
toggle that setting would be a plausible extension (IMO).

-Lester

[Message part 2 (text/html, inline)]

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lester Longley <lester <at> ieee.org>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 79652 <at> debbugs.gnu.org
Subject: Re: bug#79652: 31.0.50; incorrect filtering in
 help--symbol-completion-table
Date: Thu, 13 Nov 2025 09:39:39 -0500

>> I can see that working for someone very aware of that subtlety, but my
>> impression is that it wouldn't be useful for most users.
> ... arguably, it's not *too* subtle, since the docstrings for
> describe-function et al. mention `help-enable-completion-autoload'
> specifically:

What I meant by it, is that the user would have to know beforehand that
those autoloaded completions will get in the way.  IME they usually
don't get in the way and whether they do or not depends on the prefix of
the thing you're looking for, so it can be non-trivial to predict.

E.g. As you've discovered, `describe-` is a prefix that tends to suffer
a lot more than others because it has many autoloaded completion entries
in proportion to the "real" entries.  There are other such prefixes, but
even I (who wrote and spent a fair bit of time tweaking the algorithm
that chooses those autoloaded completions) can find it difficult to
predict which of these prefixes would tend to get in the way.


        Stefan

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Lester Longley <lester <at> ieee.org>
Cc: 79652 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#79652: 31.0.50; incorrect filtering in
 help--symbol-completion-table
Date: Thu, 13 Nov 2025 16:46:56 +0100

Lester Longley <lester <at> ieee.org> writes:

> Hello again,
>
> On Thu, Nov 13, 2025 at 8:45 AM Lester Longley <lester <at> ieee.org> wrote:
>> On Thu, Nov 13, 2025 at 5:45 AM Stefan Monnier <monnier <at> iro.umontreal.ca>
> wrote:
>> > > But it will not be possible to hide them if they are not wanted, in
>> > > case you meant via Orderless annotation filtering, since the Orderless
>> > > completion predicate gets circumvented if
>> > > `help-enable-completion-autoload' is enabled. This was the original
>> > > reason for this bug report.
>> >
>> > The UI I was imagining was the user clicking somehow (right click menu?)
>> > on those entries in *Completions*, causing the variable
>> > `help-enable-completion-autoload` to be temporarily set to nil.
>> >
>> > I don't have a clear idea how that would be implemented, and even less
>> > how that could work with corfu/company/vertico/icomplete/...
>>
>> Would it be possible (& make sense?) for orderless-all-completions (→
> orderless-filter → help--symbol-completion-table) to temp. turn off
> 'help-enable-completion-autoload' ?
>
> I.e., when an orderless annotation is in use.
>
> Though I suppose that's a bit hacky.

Yes, too hacky for my taste.

> Going back to this point:
>
>>> It occurs to me that it could be useful to allow describe-function,
>>> describe-command, etc.
>>> to be dynamically controlled, say with a prefix argument (C-u),
>>> to invert the `help-enable-completion-autoload' setting.
>>> (I don't see that these commands currently use a prefix argument.)
>>
>> I can see that working for someone very aware of that subtlety, but my
>> impression is that it wouldn't be useful for most users.
>
> ... arguably, it's not *too* subtle, since the docstrings for
> describe-function et al. mention `help-enable-completion-autoload'
> specifically:

I think toggling `help-enable-completion-autoload' is not important
enough to waste the prefix argument for that.

Daniel

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

From: Lester Longley <lester <at> ieee.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 79652 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#79652: 31.0.50;
 incorrect filtering in help--symbol-completion-table
Date: Thu, 13 Nov 2025 10:55:17 -0500

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

Daniel, Stefan - understood.  Thank you both for your help and
consideration.  Regards, Lester

On Thu, Nov 13, 2025 at 10:47 AM Daniel Mendler <mail <at> daniel-mendler.de>
wrote:
>
> Lester Longley <lester <at> ieee.org> writes:
>
> > Hello again,
> >
> > On Thu, Nov 13, 2025 at 8:45 AM Lester Longley <lester <at> ieee.org> wrote:
> >> On Thu, Nov 13, 2025 at 5:45 AM Stefan Monnier <
monnier <at> iro.umontreal.ca>
> > wrote:
> >> > > But it will not be possible to hide them if they are not wanted, in
> >> > > case you meant via Orderless annotation filtering, since the
Orderless
> >> > > completion predicate gets circumvented if
> >> > > `help-enable-completion-autoload' is enabled. This was the original
> >> > > reason for this bug report.
> >> >
> >> > The UI I was imagining was the user clicking somehow (right click
menu?)
> >> > on those entries in *Completions*, causing the variable
> >> > `help-enable-completion-autoload` to be temporarily set to nil.
> >> >
> >> > I don't have a clear idea how that would be implemented, and even
less
> >> > how that could work with corfu/company/vertico/icomplete/...
> >>
> >> Would it be possible (& make sense?) for orderless-all-completions (→
> > orderless-filter → help--symbol-completion-table) to temp. turn off
> > 'help-enable-completion-autoload' ?
> >
> > I.e., when an orderless annotation is in use.
> >
> > Though I suppose that's a bit hacky.
>
> Yes, too hacky for my taste.
>
> > Going back to this point:
> >
> >>> It occurs to me that it could be useful to allow describe-function,
> >>> describe-command, etc.
> >>> to be dynamically controlled, say with a prefix argument (C-u),
> >>> to invert the `help-enable-completion-autoload' setting.
> >>> (I don't see that these commands currently use a prefix argument.)
> >>
> >> I can see that working for someone very aware of that subtlety, but my
> >> impression is that it wouldn't be useful for most users.
> >
> > ... arguably, it's not *too* subtle, since the docstrings for
> > describe-function et al. mention `help-enable-completion-autoload'
> > specifically:
>
> I think toggling `help-enable-completion-autoload' is not important
> enough to waste the prefix argument for that.
>
> Daniel

[Message part 2 (text/html, inline)]

Previous Next

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