GNU bug report logs -
#74617
30.0.92; ffap-menu always displays the *Completions* buffer
Previous Next
Reported by: Daniel Mendler <mail <at> daniel-mendler.de>
Date: Sat, 30 Nov 2024 07:03:01 UTC
Severity: normal
Found in version 30.0.92
Done: Daniel Mendler <mail <at> daniel-mendler.de>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Juri Linkov <juri <at> linkov.net> writes:
>> The pattern where completion commands want to display candidates
>> immediately is not uncommon. There are ffap, tmm and multiple
>> third-party packages which have such a requirement. So I suggest to not
>> necessarily treat "immediate candidate display" as a bug report, but
>> rather as a feature request for `completing-read'.
>
> And imenu.el calls minibuffer-completion-help conditionally
> unless imenu-eager-completion-buffer is not nil.
Thanks, I wasn't aware of this option. It seems the behavior is
inverted? The completion buffer pops up if imenu-eager-completion-buffer
is nil.
(defcustom imenu-eager-completion-buffer t
"If non-nil, eagerly pop up the completion buffer."
:type 'boolean
:version "22.1")
It is likely that there are more such uses in the Emacs code and other
packages. One possible solution would be a display-eager metadata:
(completing-read "Test: "
(lambda (string pred action)
(if (eq action 'metadata)
'(metadata (display-eager . t))
(complete-with-action action #'read-file-name-internal string pred))))
This pushes the responsibility of displaying the candidates to
`completing-read'. In `completing-read-default' the following code
would have to be added to the `minibuffer-with-setup-hook':
(when (completion-metadata-get
(completion-metadata "" minibuffer-completion-table nil)
'display-eager)
(minibuffer-completion-help))
Daniel
This bug report was last modified 162 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.