Integration with package Breadcrumb

[nemethf]

I had a discussion with @sebastianpoeplau regarding a bug he reported against Eglot, which led me here. Although I do not use consult-imenu, it seems to me consult-imenu could take advantage of the text-properties provided by breadcrumb on top of the normal imenu interface.

class Foo {
  void bar() {}
};

Eglot/breadcrumb sets the imenu--index-alist for the file above to this:

((#("Foo" 0 3 (breadcrumb-region (1 . 31) breadcrumb-kind "Class"))
  (#("bar" 0 3 (breadcrumb-region (15 . 28) breadcrumb-kind "Method"))
   . 15)))

What do you think?

[minad]

@nemethf I am not sure if we should add special support to consult-imenu. The command supports the entirety of the Imenu data structure, but does not support extensions beyond that. I wonder why Breadcrumb modifies the Imenu - doesn't it only use Imenu to obtain the nesting of the current location? Sebastian also stated in the bug report that he considers the imenu and consult-imenu behavior in its current form correct. It is not completely clear to me what you want to achieve or what you mean by "taking advantage". Should consult-imenu display additional information or behave differently?

EDIT: I just looked at the Eglot source and the breadcrumb properties actually come from Eglot. Why is it not possible for Eglot to create a compatible Imenu data structure where top level entries are duplicated such that they can be jumped to independently?

[nemethf]

First, there is the breadcrumb-kind property, which consult could show somehow. And it could also highlight the complete region of the item not just the first line in its preview.

I think Sebastian's original idea was exactly what you suggest to duplicate the top level entries, but that does not really help to overcome the shortcomings of the menu-bar version of imenu. The way I understand it, João (the author of breadcrumb and eglot) thinks the imenu api is kind of broken and it is too much effort to fix it. But with the additional text properties a new API can emerge, which other packages can use.

I think this analogous how emacs's completion-extra-properties defines some extra properties to completion items like :annotation-function, but company adds its own properties (e.g., :company-docsig), which now consult and other completion frameworks have started using as well.

---

If consult provides a completing-read-function, then I think an enriched M-x imenu RET can be achieved with breadcrumb-jump, which is better than breadcrumb-jump and imenu, but it may lead to a better interface if consult-imenu directly reads the extra text-properties.

[minad]

I think Sebastian's original idea was exactly what you suggest to duplicate the top level entries, but that does not really help to overcome the shortcomings of the menu-bar version of imenu. The way I understand it, João (the author of breadcrumb and eglot) thinks the imenu api is kind of broken and it is too much effort to fix it. But with the additional text properties a new API can emerge, which other packages can use.

I think one can duplicate the entries with different names, e.g., Foo (top) and Foo. This should work with the menu bar, imenu and consult-imenu. However this solution is a bit ugly. João also suggested to improve the Imenu data structure. One could even go so far and introduce a new incompatible data structure, which makes sense given the current limitations regarding inner and leaf nodes. The imenu command and the menu bar should also support the new format.

[nemethf]

At any rate, I just wanted to draw you attention this eglot/breadcrumb feature. If you think other packages should adapt to consult-imenu (and the current imenu data structure) or someone should reform imenu, that is perfectly understandable.

[sebastianpoeplau]

It also seems possible to construct a data structure that works with imenu as before (i.e., without a way to jump to container symbols, but no regressions either) and presents full information in consult-imenu - that's what I get with servers triggering eglot--imenu-SymbolInformation, e.g., pylsp. I think the trick is that it puts the entry for the symbol behind the entry for the container:

;; imenu--index-alist, trimmed manually and without text properties
(("Function" (("sync_tree" ("path_key" . 20862))
              ("sync_tree" . 18754))))

The Python code that it represents contains something like this:

def sync_tree(...):
    ...

    def path_key(...):
        ...

    ...