GNU bug report logs - #52389
29.0.50; Imenu does not pop up the Completions eagerly

Previous Next

To reply to this bug, email your comments to 52389 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: Protesilaos Stavrou <info <at> protesilaos.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Imenu does not pop up the Completions eagerly
Date: Thu, 09 Dec 2021 15:32:11 +0200

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

Dear maintainers,

I think the current behaviour of 'imenu-eager-completion-buffer' is
counter-intuitive.  Its default value is non-nil, while its doc string
tells us that:

    If non-nil, eagerly popup the completion buffer.

This, however, is not what actually happens.  With 'emacs -Q':

+ Include a demo function in the scratch buffer: (defun test-fn ())
+ M-x imenu
+ Here we expect the Completions' buffer to eagerly pop up, yet it does
  not.
+ M-: (setq imenu-eager-completion-buffer nil)
+ M-x imenu
+ The Completions' buffer now pops up automatically.

Do you agree that this is counter-intuitive?  If so, please find
attached a patch that should fix the issue.  I was not sure this was
NEWSworthy, but I included an entry regardless.

All the best,
Protesilaos

-- 
Protesilaos Stavrou
https://protesilaos.com

[0001-Fix-semantics-of-imenu-eager-completion-buffer.patch (text/x-patch, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Protesilaos Stavrou <info <at> protesilaos.com>
Cc: 52389 <at> debbugs.gnu.org
Subject: Re: bug#52389: 29.0.50; Imenu does not pop up the Completions eagerly
Date: Fri, 10 Dec 2021 12:51:18 +0100

Protesilaos Stavrou <info <at> protesilaos.com> writes:

> * lisp/imenu.el (imenu-eager-completion-buffer): Set the default value
> to nil, as that was the intended one.
> (imenu--completion-buffer): Update the condition to check for a
> non-nil value to 'imenu-eager-completion-buffer'.

But you're reversing the logic, so that people who have set this to nil
now won't get an eager pop up?

I don't think we can do that.  The documentation (and indeed the name of
the variable) seems to be wrong, though.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Protesilaos Stavrou <info <at> protesilaos.com>, 52389 <at> debbugs.gnu.org
Subject: Re: bug#52389: 29.0.50; Imenu does not pop up the Completions eagerly
Date: Fri, 10 Dec 2021 16:16:47 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Protesilaos Stavrou <info <at> protesilaos.com> writes:
>
>> * lisp/imenu.el (imenu-eager-completion-buffer): Set the default value
>> to nil, as that was the intended one.
>> (imenu--completion-buffer): Update the condition to check for a
>> non-nil value to 'imenu-eager-completion-buffer'.
>
> But you're reversing the logic, so that people who have set this to nil
> now won't get an eager pop up?
>
> I don't think we can do that.  The documentation (and indeed the name of
> the variable) seems to be wrong, though.

I think the safest way to solve this long-standing problem without
surprising users is to introduce a new variable whose logic is handled
correctly, and mark imenu-eager-completion-buffer as deprecated.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: Protesilaos Stavrou <info <at> protesilaos.com>, 52389 <at> debbugs.gnu.org
Subject: Re: bug#52389: 29.0.50; Imenu does not pop up the Completions eagerly
Date: Sat, 11 Dec 2021 04:25:25 +0100

Daniel Martín <mardani29 <at> yahoo.es> writes:

> I think the safest way to solve this long-standing problem without
> surprising users is to introduce a new variable whose logic is handled
> correctly, and mark imenu-eager-completion-buffer as deprecated.

Sounds good to me.  (The new variable could be an alias of the old name,
but have a name with the opposite meaning, and then things would
continue to work for everybody.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Protesilaos Stavrou <info <at> protesilaos.com>, 52389 <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#52389: 29.0.50; Imenu does not pop up the Completions eagerly
Date: Sat, 11 Dec 2021 22:16:01 +0200

>> I think the safest way to solve this long-standing problem without
>> surprising users is to introduce a new variable whose logic is handled
>> correctly, and mark imenu-eager-completion-buffer as deprecated.
>
> Sounds good to me.  (The new variable could be an alias of the old name,
> but have a name with the opposite meaning, and then things would
> continue to work for everybody.)

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.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: Protesilaos Stavrou <info <at> protesilaos.com>, 52389 <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#52389: 29.0.50; Imenu does not pop up the Completions eagerly
Date: Sun, 12 Dec 2021 05:58:28 +0100

Juri Linkov <juri <at> linkov.net> writes:

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

Hm...  I think that sounds rather confusing...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Protesilaos Stavrou <info <at> protesilaos.com>
To: Juri Linkov <juri <at> linkov.net>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 52389 <at> debbugs.gnu.org, Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#52389: 29.0.50; Imenu does not pop up the Completions eagerly
Date: Sun, 12 Dec 2021 08:09:07 +0200

On 2021-12-11, 22:16 +0200, Juri Linkov <juri <at> linkov.net> wrote:

>>> I think the safest way to solve this long-standing problem without
>>> surprising users is to introduce a new variable whose logic is handled
>>> correctly, and mark imenu-eager-completion-buffer as deprecated.
>>
>> Sounds good to me.  (The new variable could be an alias of the old name,
>> but have a name with the opposite meaning, and then things would
>> continue to work for everybody.)
>
> 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>.

-- 
Protesilaos Stavrou
https://protesilaos.com

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

From: Juri Linkov <juri <at> linkov.net>
To: Protesilaos Stavrou <info <at> protesilaos.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 52389 <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#52389: 29.0.50; Imenu does not pop up the Completions eagerly
Date: Sun, 12 Dec 2021 19:36:15 +0200

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

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.

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

From: Protesilaos Stavrou <info <at> protesilaos.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 52389 <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#52389: 29.0.50; Imenu does not pop up the Completions eagerly
Date: Mon, 13 Dec 2021 09:20:47 +0200

On 2021-12-12, 19:36 +0200, Juri Linkov <juri <at> 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

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

From: Juri Linkov <juri <at> linkov.net>
To: Protesilaos Stavrou <info <at> protesilaos.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 52389 <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#52389: 29.0.50; Imenu does not pop up the Completions eagerly
Date: Mon, 13 Dec 2021 10:53:59 +0200

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

It seems everyone agrees here it would be preferable to
rewrite the patch using define-obsolete-variable-alias.

Any generalization that uses current-minibuffer-command
could be implemented later, without impeding the fix
for this bug report.

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

From: Protesilaos Stavrou <info <at> protesilaos.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 52389 <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#52389: 29.0.50; Imenu does not pop up the Completions eagerly
Date: Fri, 17 Dec 2021 13:57:52 +0200

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

On 2021-12-13, 10:53 +0200, Juri Linkov <juri <at> linkov.net> wrote:

>> 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?
>
> It seems everyone agrees here it would be preferable to
> rewrite the patch using define-obsolete-variable-alias.

Please find attached the patch that implements the new user option.  I
did not include a NEWS entry as things should work the way they did
before.

The combined use of "not" and "no" concepts in this case feels awkward.
I prefer my original approach of changing the logic, though I understand
it would be backward-incompatible.

-- 
Protesilaos Stavrou
https://protesilaos.com

[0001-Deprecate-Imenu-option-for-eager-completion-buffer.patch (text/x-patch, attachment)]

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

From: André A. Gomes <andremegafone <at> gmail.com>
To: Protesilaos Stavrou <info <at> protesilaos.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 Daniel Martín <mardani29 <at> yahoo.es>, 52389 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#52389: 29.0.50; Imenu does not pop up the Completions eagerly
Date: Fri, 17 Dec 2021 12:34:58 +0000

Protesilaos Stavrou <info <at> protesilaos.com> writes:

> On 2021-12-13, 10:53 +0200, Juri Linkov <juri <at> linkov.net> wrote:
>
>>> 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?
>>
>> It seems everyone agrees here it would be preferable to
>> rewrite the patch using define-obsolete-variable-alias.
>
> Please find attached the patch that implements the new user option.  I
> did not include a NEWS entry as things should work the way they did
> before.
>
> The combined use of "not" and "no" concepts in this case feels awkward.
> I prefer my original approach of changing the logic, though I understand
> it would be backward-incompatible.

Agreed.  I don't understand how the decision moved in this direction.
Perhaps the maintainers will reconsider.


-- 
André A. Gomes
"Free Thought, Free World"

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Protesilaos Stavrou <info <at> protesilaos.com>
Cc: larsi <at> gnus.org, mardani29 <at> yahoo.es, 52389 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#52389: 29.0.50; Imenu does not pop up the Completions eagerly
Date: Fri, 17 Dec 2021 14:55:17 +0200

> From: Protesilaos Stavrou <info <at> protesilaos.com>
> Date: Fri, 17 Dec 2021 13:57:52 +0200
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 52389 <at> debbugs.gnu.org,
>  Daniel Martín <mardani29 <at> yahoo.es>
> 
> +(defcustom imenu-no-eager-completion-buffer t
> +  "If non-nil, do not eagerly popup the completion buffer."

The doc string should go on to explain what does it mean to "eagerly
popup a buffer".  It is not self-evident.

(Yes, I know this was in the original text, but while we are at that,
we might as well fix that omission.)

Thanks.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Protesilaos Stavrou <info <at> protesilaos.com>, mardani29 <at> yahoo.es,
 52389 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#52389: 29.0.50; Imenu does not pop up the Completions eagerly
Date: Sat, 18 Dec 2021 08:44:50 +0100

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

>> +(defcustom imenu-no-eager-completion-buffer t
>> +  "If non-nil, do not eagerly popup the completion buffer."
>
> The doc string should go on to explain what does it mean to "eagerly
> popup a buffer".  It is not self-evident.
>
> (Yes, I know this was in the original text, but while we are at that,
> we might as well fix that omission.)

And I don't think we should call a variable
`imenu-no-eager-completion-buffer' -- it's very confusing.
`imenu-inhibit-eager-completion-buffer' is better.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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