Re: master 431f8ff1e38: * lisp/imenu.el: Support more values for imenu-flatten (bug#70846)

[Eshel Yaron <me@eshelyaron.com>]

Hi Juri,

Juri Linkov <juri@linkov.net> writes:

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

I forgot to mention that this also affects using previous minibuffer
inputs with M-p: the text properties aren't recorded in the history
list, so you get an ambiguous input that doesn't always take you to
where you went when you previously used that input.

>> What I would suggest is to ensure completion candidates are unambiguous
>> as strings rather than relying on text properties.  Namely:
>
> Unfortunately, that'd be a step back.  Maybe at least we could document
> limitations that annotations work only by selection.

Indeed my suggestion was to take a step back of sorts.  If it's too late
for that, I agree it's a good idea to document the known issues.
>
>> - 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.
>
> It can't be boolean, because a more reliable replacement for annotations
> would be appending the suffix, i.e. by the new value 'suffix'.

That makes sense.

>> - 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.
>
> The disadvantage of completions-group is its too wide coverage.
> We should strive for more specific options where possible.

Right.  The advantage, on the other hand, is that you can toggle
completions-group on the fly in the minibuffer, either with
toggle-option or with a dedicated command.  The wide coverage of
completions-group means there's just one variable to toggle, always.

> Or better: let's enable groups by category.  I don't know why we have
> such a glaring omission that groups still can't be enabled by
> category.  This should be simple to implement:

Doesn't the group-function metadata entry give enough control already?
If a category or a specific completion table wants to disable grouping,
it can simply avoid providing a group-function.  If it wants to enable
grouping, then it does provide a group-function, and now it's up to the
user's preferences which they express by setting completions-group.
Maybe your suggestion yields more flexibility in some cases?


Best,

Eshel