bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#52389: 29.0.50; Imenu does not pop up the Completions eagerly


From: Protesilaos Stavrou
Subject: bug#52389: 29.0.50; Imenu does not pop up the Completions eagerly
Date: Mon, 13 Dec 2021 09:20:47 +0200
User-agent: Notmuch/0.34.1 (https://notmuchmail.org) Emacs/29.0.50 (x86_64-pc-linux-gnu)

On 2021-12-12, 19:36 +0200, Juri Linkov <juri@linkov.net> wrote:

>>> This is a good opportunity for generalization.
>>> Like there is icomplete-show-matches-on-no-input,
>>> would it be possible to create a new user option
>>> e.g. minibuffer-auto-show-completions, and allow
>>> to customize what commands should use it.
>>> Then it could be like completion-auto-select
>>> recently proposed by Philip.
>>
>> That is possible with my mct package on GNU ELPA.  It has the option of
>> a passlist for commands that should eagerly pop up the Completions'
>> buffer.
>>
>> [ Philip mentioned mct in those patches. ]
>>
>> Note, however, that the case here with Imenu is different because even
>> if you pop the completions eagerly upon M-x imenu, you still need to
>> handle the case of nested Imenu entries.  That is what the user option
>> imenu-eager-completion-buffer helps deal with.  Actually, what prompted
>> me to report this bug was due to an issue in the mct repo, where I
>> discovered the confusing doc string of that Imenu user option:
>> <https://gitlab.com/protesilaos/mct/-/issues/12>.
>
> Thanks for the reference, I see the problem now: after adding ‘imenu’ to
> mct-completion-passlist, ‘M-x imenu RET’ auto-displays completions
> correctly.  But the problem is that selecting e.g. a nested completion
> doesn't auto-display the nested completion list, because in the first
> case ‘this-command’ is ‘imenu’, but in the second case it's a command
> that selects the nested completion.
>
> Fortunately, it's possible to solve this problem using
> the new variable introduced in 28.1: ‘current-minibuffer-command’
> that is like ‘this-command’, but preserves its value
> during the nested minibuffer activities.  To make it
> backward-compatibile with Emacs 27.1, 'bound-and-true-p'
> could help to check if the variable is defined, e.g.
>
> #+begin_src emacs-lisp
>    ((memq (or (bound-and-true-p current-minibuffer-command)
>               this-command)
>           mct-completion-passlist)
> #+end_src
>
> Then 'imenu' in 'mct-completion-passlist' will be available
> for the nested minibuffer commands.

Update things accordingly.  Thank you!

> PS: Overall, your package mct makes progress towards better
> minibuffer/completions interactions.  However, its behaviour
> can't be enabled by default in Emacs, because e.g. such keys
> as up/down arrows traditionally are used for history navigation.

That's okay.  I thought it was worth putting it on GNU ELPA as a
proof-of-concept.  Patching Emacs the way Philip suggests should be the
right way forward.

* * *

Regarding this bug report, I am not sure what the status is.  Should I
rewrite the patch to specify a define-obsolete-variable-alias instead?
Or is someone else taking care of it?

-- 
Protesilaos Stavrou
https://protesilaos.com

reply via email to

[Prev in Thread] Current Thread [Next in Thread]