[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: master 431f8ff1e38: * lisp/imenu.el: Support more values for imenu-f
From: |
Eshel Yaron |
Subject: |
Re: master 431f8ff1e38: * lisp/imenu.el: Support more values for imenu-flatten (bug#70846) |
Date: |
Sun, 14 Jul 2024 12:55:53 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Juri Linkov <juri@linkov.net> writes:
>> I'm afraid imenu-flatten=annotation has one more hurdle to overcome.
>> Consider:
>>
>> 1. emacs -Q
>> 2. (setq imenu-flatten 'annotation)
>> 2. C-x C-f .../lisp/imenu.el
>> 3. M-g i
>> 4. M-<down> M-<down> M-<down> M-<down> ...
>> 5. Now the selected candidate in *Completions* is e.g. imenu--cleanup,
>> this is also the minibuffer contents, so far so good.
>> 6. Type M-RET to jump to this candidate.
>> 7. Land on imenu instead of imenu--cleanup.
>>
>> No matter how far down you go with M-<down>, if you go through the entry
>> for imenu, that's where you'll land when you hit M-RET. This is because
>> imenu-flatten=annotation tries to identify candidates by their text
>> properties, but completion--replace retains common parts while replacing
>> minibuffer text, along with the text properties of these common parts.
>>
>> This affects imenu-flatten=group too.
>>
>> It might be possible to resolve this by setting a different
>> completion-list-insert-choice-function that circumvents replaces the
>> whole minibuffer contents, unlike completion--replace, which tries hard
>> to preserve markers etc.
>
> Maybe then imenu--completion-buffer should try to get the text property
> from the end of completion? Provided that completion--replace will keep
> some properties at the end instead of using insert-and-inherit.
I'm not sure, I think that might work in some cases, but since
completion--replace also keeps the common suffix it may still suffer
from the same issue when going from candidate "foo-baz" to "bar-baz".
Then there's the problem of what happens when you simply type the
candidate you want to jump to, without completion. For example
M-g i imenu RET goes to the imenu function when imenu-flatten=nil,
but if imenu-flatten=annotation then it goes to the defgroup.
What I would suggest is to ensure completion candidates are unambiguous
as strings rather than relying on text properties. Namely:
- Restore imenu-flatten to a boolean option: either flat or nested.
- If imenu-flatten is non-nil, prepend the full prefix to each candidate,
like imenu-flatten=prefix does currently. This takes care of
disambiguating the candidate strings.
- If completions-group is also non-nil, then group candidates according
to their prefix and trim the prefix in the group-function when
transforming candidates for display.
Best,
Eshel