GNU bug report logs - #58431
29.0.50; [Eglot] Add "breadcrumb.el" feature based on imenu.el/project.el services

Previous Next

To reply to this bug, email your comments to 58431 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: João Távora <joaotavora <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Cc: eliz <at> gnu.org
Subject: 29.0.50; [Eglot] Add "breadcrumb.el" feature based on
 imenu.el/project.el services
Date: Tue, 11 Oct 2022 10:17:20 +0100

Hello,

This request for a "breadcrumb" feature started in Eglot's bug tracker:
   
   https://github.com/joaotavora/eglot/discussions/988

Put it short, a breadcrumb is a summarized indication of the full path
to the current location of point within a source file.  So if I have a
file 'baz.cpp' inside a directory 'bars' of a project directory 'foo'
and that file contains:

    class Baz {
          int quux() {
              return 42; // point here
          }

          // or here
    };

Then the breadcrumb would read:

    foo > bars > baz.cpp > Baz > quux

If I move my point to outside quux(), the breadcrumb should now read:

    foo > bars > baz.cpp > Baz

The preferred location of this breadcrumb readout should be the
headerline.

In the original Eglot request, users are requesting this UI feature for
the Eglot LSP client.  But this doesn't have any LSP-specific
interactions.  It can and should be done entirely by using the services
provided by imenu.el and project.el.

Eglot already integrates with Imenu, so as soon as this hypothetical
breadcrumb.el is in place, then Eglot users can take advantage of it.

This is similar to which-func.el, which displays the trailing element of
the breadcrumb in the headerline.  Perhaps the breadcrumb feature can be
thought of as an augmentation of which-func.el's functionality.  I don't
have a strong opinion there.

João

PS: Eli, I'm CCing you to underline this as just an example of a UI
feature that is requested for Eglot, but belongs somewhere else.  In
this case, I believe there is 0 additional integration needed in
eglot.el: it can be realized independently of the backend which feeds
into Imenu (perhaps tree-sitter?) and project.el.

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

From: Yuan Fu <casouri <at> gmail.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: eliz <at> gnu.org, 58431 <at> debbugs.gnu.org
Subject: Re: bug#58431: 29.0.50; [Eglot] Add "breadcrumb.el" feature based on
 imenu.el/project.el services
Date: Tue, 11 Oct 2022 08:38:30 -0700

> In the original Eglot request, users are requesting this UI feature for
> the Eglot LSP client.  But this doesn't have any LSP-specific
> interactions.  It can and should be done entirely by using the services
> provided by imenu.el and project.el.
> 
> Eglot already integrates with Imenu, so as soon as this hypothetical
> breadcrumb.el is in place, then Eglot users can take advantage of it.
> 
> This is similar to which-func.el, which displays the trailing element of
> the breadcrumb in the headerline.  Perhaps the breadcrumb feature can be
> thought of as an augmentation of which-func.el's functionality.  I don't
> have a strong opinion there.

I think which-func is closer to breadcrumb conceptually and api-wise: Both which-func and breadcrumb are about the current function, while imenu is about a list of _all_ functions/sections. We could just allow which-func-function to accept a list of function names. In fact, the which-func function of tree-sitter powered python.el already generates a breadcrumb, I just joined all the function names along the path with “/“. 

> 
> João
> 
> PS: Eli, I'm CCing you to underline this as just an example of a UI
> feature that is requested for Eglot, but belongs somewhere else.  In
> this case, I believe there is 0 additional integration needed in
> eglot.el: it can be realized independently of the backend which feeds
> into Imenu (perhaps tree-sitter?) and project.el.

I agree, Emacs provides the framework/UI, and tree-sitter/eglot/future magic plug in.

Yuan

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

From: João Távora <joaotavora <at> gmail.com>
To: Yuan Fu <casouri <at> gmail.com>
Cc: eliz <at> gnu.org, 58431 <at> debbugs.gnu.org
Subject: Re: bug#58431: 29.0.50; [Eglot] Add "breadcrumb.el" feature based
 on imenu.el/project.el services
Date: Wed, 12 Oct 2022 00:50:09 +0100

Yuan Fu <casouri <at> gmail.com> writes:

>> In the original Eglot request, users are requesting this UI feature for
>> the Eglot LSP client.  But this doesn't have any LSP-specific
>> interactions.  It can and should be done entirely by using the services
>> provided by imenu.el and project.el.
>>
>> Eglot already integrates with Imenu, so as soon as this hypothetical
>> breadcrumb.el is in place, then Eglot users can take advantage of it.
>>
>> This is similar to which-func.el, which displays the trailing element of
>> the breadcrumb in the headerline.  Perhaps the breadcrumb feature can be
>> thought of as an augmentation of which-func.el's functionality.  I don't
>> have a strong opinion there.
>
> I think which-func is closer to breadcrumb conceptually and api-wise:
> Both which-func and breadcrumb are about the current function, while
> imenu is about a list of _all_ functions/sections.

I think there is a slight misunderstanding here.

The information stored in imenu is what which-func.el uses by default.
See this comment in which-func.el

   ;; This package prints name of function where your current point is
   ;; located in mode line.  It assumes that you work with the imenu
   ;; package and `imenu--index-alist' is up to date.

Moreover, imenu--index-alist is not a list, but a tree (of which a flat
list is a particular case).

M-x which-function-mode works for any Eglot-managed buffer, but Eglot
doesn't have any code specific to which-func.el.  How can this be?
Well, Eglot stores the tree information is gets from LSP in Imenu's
imenu--index-alist and that information serves many Imenu frontends --
which-func.el being just one of them.

Moreover, the breadcrumb that the Eglot user is requesting -- and which
I am describing in detail -- also needs information that is owned by
project.el, namely the project root.

Let's use some M-x artist-mode magic to explain what is in place
and what I am proposing.

+---+----+   +---------+     +----------+
|eglot.el|   |python.el|     | ruby.el  |
+---+----+   +---+-----+     +----+-----+
    |            |                |
    |            |                |
    |            v                |
    |        +----------+         |
    +------->| imenu.el |<--------+
             +-+--------+
               |
+--------------+
|
|  +-------------------+
\->|which-func.el      |
|  |(already working)  |
|  +-------------------+
|
|  +-------------------+
\->|speedbar.el        |
|  |(also working)     |
|  +-------------------+
|
|  +-------------------+
\->|...                |
|  +-------------------+         +--------------+
|                                |  project.el  |
|  o-------------------o         +--------------+
\->|breadcrumb.el      |             /
   |(proposed addition)|<------------ 
   o-------------------o

So, Eglot already stores its LSP-gathered information "inside" imenu's
data structures using imenu-create-index-function.  As does the current
python.el, ruby.el, antlr-mode.el, cc-mode and many others when they are
used without Eglot.

which-func.el get this information from imenu and uses it for the limited
purpose of showing only the leaf of the tree where the point is at.

breadcrumb.el would function similarly, but instead use it to show the
_full path_ of that tree up until the leaf of the tree where the point
is at.  It would then prepend the path to the file by getting it from
project.el.

> which-func-function to accept a list of function names. In fact, the
> which-func function of tree-sitter powered python.el already generates
> a breadcrumb, I just joined all the function names along the path with
> “/“.

You can use that strategy in your new Python mode, but it seems
misguided to me.  You'll be supporting which-func.el directly instead of
indirectly, thus missing out on other imenu-using client frontends like
speedbar, "treemacs", M-x imenu or others.  They will not work
out-of-the-box with your new mode.

Therefore, my advice is that you keep the tree structure you get from
tree-sitter intact and stored in imenu--index-alist via
imenu-create-index-function -- see the docstring imenu--index-alist --
then let the imenu clients compose a breadcrumb iff they so desire.

breadcrumb.el would be such a client, that would work in your
tree-sitter powered python mode and in many other contexts.

João

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

From: Yuan Fu <casouri <at> gmail.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: eliz <at> gnu.org, 58431 <at> debbugs.gnu.org
Subject: Re: bug#58431: 29.0.50; [Eglot] Add "breadcrumb.el" feature based on
 imenu.el/project.el services
Date: Tue, 11 Oct 2022 23:22:48 -0700

> On Oct 11, 2022, at 4:50 PM, João Távora <joaotavora <at> gmail.com> wrote:
> 
> Yuan Fu <casouri <at> gmail.com> writes:
> 
>>> In the original Eglot request, users are requesting this UI feature for
>>> the Eglot LSP client.  But this doesn't have any LSP-specific
>>> interactions.  It can and should be done entirely by using the services
>>> provided by imenu.el and project.el.
>>> 
>>> Eglot already integrates with Imenu, so as soon as this hypothetical
>>> breadcrumb.el is in place, then Eglot users can take advantage of it.
>>> 
>>> This is similar to which-func.el, which displays the trailing element of
>>> the breadcrumb in the headerline.  Perhaps the breadcrumb feature can be
>>> thought of as an augmentation of which-func.el's functionality.  I don't
>>> have a strong opinion there.
>> 
>> I think which-func is closer to breadcrumb conceptually and api-wise:
>> Both which-func and breadcrumb are about the current function, while
>> imenu is about a list of _all_ functions/sections.
> 
> I think there is a slight misunderstanding here.
> 
> The information stored in imenu is what which-func.el uses by default.
> See this comment in which-func.el
> 
>   ;; This package prints name of function where your current point is
>   ;; located in mode line.  It assumes that you work with the imenu
>   ;; package and `imenu--index-alist' is up to date.
> 
> Moreover, imenu--index-alist is not a list, but a tree (of which a flat
> list is a particular case).
> 
> M-x which-function-mode works for any Eglot-managed buffer, but Eglot
> doesn't have any code specific to which-func.el.  How can this be?
> Well, Eglot stores the tree information is gets from LSP in Imenu's
> imenu--index-alist and that information serves many Imenu frontends --
> which-func.el being just one of them.
> 
> Moreover, the breadcrumb that the Eglot user is requesting -- and which
> I am describing in detail -- also needs information that is owned by
> project.el, namely the project root.
> 
> Let's use some M-x artist-mode magic to explain what is in place
> and what I am proposing.
> 
> +---+----+   +---------+     +----------+
> |eglot.el|   |python.el|     | ruby.el  |
> +---+----+   +---+-----+     +----+-----+
>    |            |                |
>    |            |                |
>    |            v                |
>    |        +----------+         |
>    +------->| imenu.el |<--------+
>             +-+--------+
>               |
> +--------------+
> |
> |  +-------------------+
> \->|which-func.el      |
> |  |(already working)  |
> |  +-------------------+
> |
> |  +-------------------+
> \->|speedbar.el        |
> |  |(also working)     |
> |  +-------------------+
> |
> |  +-------------------+
> \->|...                |
> |  +-------------------+         +--------------+
> |                                |  project.el  |
> |  o-------------------o         +--------------+
> \->|breadcrumb.el      |             /
>   |(proposed addition)|<------------ 
>   o-------------------o
> 
> So, Eglot already stores its LSP-gathered information "inside" imenu's
> data structures using imenu-create-index-function.  As does the current
> python.el, ruby.el, antlr-mode.el, cc-mode and many others when they are
> used without Eglot.
> 
> which-func.el get this information from imenu and uses it for the limited
> purpose of showing only the leaf of the tree where the point is at.
> 
> breadcrumb.el would function similarly, but instead use it to show the
> _full path_ of that tree up until the leaf of the tree where the point
> is at.  It would then prepend the path to the file by getting it from
> project.el.
> 
>> which-func-function to accept a list of function names. In fact, the
>> which-func function of tree-sitter powered python.el already generates
>> a breadcrumb, I just joined all the function names along the path with
>> “/“.
> 
> You can use that strategy in your new Python mode, but it seems
> misguided to me.  You'll be supporting which-func.el directly instead of
> indirectly, thus missing out on other imenu-using client frontends like
> speedbar, "treemacs", M-x imenu or others.  They will not work
> out-of-the-box with your new mode.
> 
> Therefore, my advice is that you keep the tree structure you get from
> tree-sitter intact and stored in imenu--index-alist via
> imenu-create-index-function -- see the docstring imenu--index-alist --
> then let the imenu clients compose a breadcrumb iff they so desire.
> 
> breadcrumb.el would be such a client, that would work in your
> tree-sitter powered python mode and in many other contexts.
> 
> João

Thanks for your explanation! I didn’t know which-func can just use imenu--index-alist. I already have support for imenu, just need to let which-func do its thing. 

What you said for breakcumb.el makes total sense. It sounds pretty straightforward, just get file path from project.el and function path from imenu and put them together. I can work on it later if no one come around and adopt it, I’ve got a lot of stuff on my plate already ;-)

Yuan

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

From: João Távora <joaotavora <at> gmail.com>
To: Yuan Fu <casouri <at> gmail.com>
Cc: eliz <at> gnu.org, 58431 <at> debbugs.gnu.org
Subject: Re: bug#58431: 29.0.50; [Eglot] Add "breadcrumb.el" feature based
 on imenu.el/project.el services
Date: Wed, 12 Oct 2022 09:30:01 +0100

Yuan Fu <casouri <at> gmail.com> writes:

> Thanks for your explanation! I didn’t know which-func can just use
> imenu--index-alist. I already have support for imenu, just need to let
> which-func do its thing.

Yup.

> What you said for breakcumb.el makes total sense. It sounds pretty
> straightforward, just get file path from project.el and function path
> from imenu and put them together.

Yes, that's exactly it.  It should be reasonably straightforward yes.

Maybe, to make a fancy breadcrumb, with icons like lsp-mode's we will
need some small augmentations to imenu--index-alist, but I don't see
that as a big difficulty.

> I can work on it later if no one
> come around and adopt it, I’ve got a lot of stuff on my plate already
> ;-)

Same here.  Drop a line a line if start working on this, so we don't
duplicate each other's work.

João

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

From: Daniel Martín <mardani29 <at> yahoo.es>
To: João Távora <joaotavora <at> gmail.com>
Cc: eliz <at> gnu.org, 58431 <at> debbugs.gnu.org
Subject: Re: bug#58431: 29.0.50; [Eglot] Add "breadcrumb.el" feature based
 on imenu.el/project.el services
Date: Sat, 08 Apr 2023 21:47:40 +0200

João Távora <joaotavora <at> gmail.com> writes:

>
> This is similar to which-func.el, which displays the trailing element of
> the breadcrumb in the headerline.  Perhaps the breadcrumb feature can be
> thought of as an augmentation of which-func.el's functionality.  I don't
> have a strong opinion there.

I see this feature as an augmentation of which-func.el.  The purpose is
to show what is the current defun, but the how and where (mode line or
header line) is a configuration option.

In recent versions of IDEs and text editors another header line UI to
show the current function is getting popular, something like our old
Sticky Function mode.  As with this breadcrumb UI, I think its logic
belongs more to which-func-mode.el and shouldn't be coupled to Semantic.

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

From: Adam Porter <adam <at> alphapapa.net>
To: 58431 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>,
 João Távora <joaotavora <at> gmail.com>,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#58431: 29.0.50; [Eglot] Add "breadcrumb.el" feature based, on
 imenu.el/project.el services
Date: Tue, 18 Apr 2023 13:10:57 -0500

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

>> This is similar to which-func.el, which displays the trailing element of
>> the breadcrumb in the headerline.  Perhaps the breadcrumb feature can be
>> thought of as an augmentation of which-func.el's functionality.  I don't
>> have a strong opinion there.
> 
> I see this feature as an augmentation of which-func.el.  The purpose is
> to show what is the current defun, but the how and where (mode line or
> header line) is a configuration option.
> 
> In recent versions of IDEs and text editors another header line UI to
> show the current function is getting popular, something like our old
> Sticky Function mode.  As with this breadcrumb UI, I think its logic
> belongs more to which-func-mode.el and shouldn't be coupled to Semantic.

FWIW, this sounds similar to the topsy.el library I published on MELPA a 
couple of years ago.  It aims to provide similar (or better) 
functionality than semantic-stickyfunc-mode without using Semantic.

https://github.com/alphapapa/topsy.el

If any of its code would be helpful, I'd be glad to "donate" it to 
ELPA/Emacs.

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

From: João Távora <joaotavora <at> gmail.com>
To: Adam Porter <adam <at> alphapapa.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 58431 <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#58431: 29.0.50; [Eglot] Add "breadcrumb.el" feature based, on
 imenu.el/project.el services
Date: Tue, 18 Apr 2023 19:26:26 +0100

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

On Tue, Apr 18, 2023 at 7:10 PM Adam Porter <adam <at> alphapapa.net> wrote:

> FWIW, this sounds similar to the topsy.el library I published on MELPA a
> couple of years ago.  It aims to provide similar (or better)
> functionality than semantic-stickyfunc-mode without using Semantic.

Had a look, but doesn't seem to work with Imenu directly.  That's a goal
here, because it makes this work for Eglot and also any other non-Eglot
client that already defines an imenu.

Also seems to have a slightly different goal.  The goal here, is for
the headerline to show the current position in terms of the intervals
it intersects in the imenu tree, which may be a deep hierarchical
tree in some languages.

Here's what I've come up with: it's fresh out of the oven :-)

(meaning probably buggy, but hopefully hot)

João

[breadcrumb.el (text/x-emacs-lisp, attachment)]

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

From: Adam Porter <adam <at> alphapapa.net>
To: João Távora <joaotavora <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 58431 <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#58431: 29.0.50; [Eglot] Add "breadcrumb.el" feature based, on
 imenu.el/project.el services
Date: Wed, 19 Apr 2023 23:27:45 -0500

Hi João,

On 4/18/23 13:26, João Távora wrote:
> On Tue, Apr 18, 2023 at 7:10 PM Adam Porter <adam <at> alphapapa.net> wrote:
> 
>> FWIW, this sounds similar to the topsy.el library I published on MELPA a
>> couple of years ago.  It aims to provide similar (or better)
>> functionality than semantic-stickyfunc-mode without using Semantic.
> 
> Had a look, but doesn't seem to work with Imenu directly.  That's a goal
> here, because it makes this work for Eglot and also any other non-Eglot
> client that already defines an imenu.

Yes, it doesn't use any Imenu functions currently.  It's an interesting 
idea, though.

> Also seems to have a slightly different goal.  The goal here, is for
> the headerline to show the current position in terms of the intervals
> it intersects in the imenu tree, which may be a deep hierarchical
> tree in some languages.

For most modes, that's true.  For buffers using `magit-section-mode', 
the `topsy--magit-section' function does return a breadcrumbs-style list 
that shows the hierarchy of sections.  Also, my other package that's 
just for Org, org-sticky-header, does show a breadcrumbs-style list of 
ancestor headings.

> Here's what I've come up with: it's fresh out of the oven :-)
> 
> (meaning probably buggy, but hopefully hot)

Thanks.  I tried it, and I'm not sure if it's doing what you intend, but 
it doesn't seem to do what I need; that is, it doesn't show the 
beginning of the top-level form that encloses the line at the top of the 
window.

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

From: João Távora <joaotavora <at> gmail.com>
To: Adam Porter <adam <at> alphapapa.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 58431 <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#58431: 29.0.50; [Eglot] Add "breadcrumb.el" feature based,
 on imenu.el/project.el services
Date: Thu, 20 Apr 2023 10:22:53 +0100

Adam Porter <adam <at> alphapapa.net> writes:

> For most modes, that's true.  For buffers using `magit-section-mode',
> the `topsy--magit-section' function does return a breadcrumbs-style
> list that shows the hierarchy of sections.  Also, my other package
> that's just for Org, org-sticky-header, does show a breadcrumbs-style
> list of ancestor headings.

I don't use Magit.  If its buffer support Imenu in any way, then
breadcrumb should do something.

>> Here's what I've come up with: it's fresh out of the oven :-)
>> (meaning probably buggy, but hopefully hot)
>
> Thanks.  I tried it, and I'm not sure if it's doing what you intend,
> but it doesn't seem to do what I need; that is, it doesn't show the
> beginning of the top-level form that encloses the line at the top of
> the window.

Its impossible for me to know what you are trying to do with it doing
with this description.  Is this in a file?  Can you show the file?  If
it's not a file, can you describe how I can test what you're testing?

João

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

From: João Távora <joaotavora <at> gmail.com>
To: Yuan Fu <casouri <at> gmail.com>, Jeremy Bryant <jb <at> jeremybryant.net>, 
 Daniel Martín <mardani29 <at> yahoo.es>, 
 Adam Porter <adam <at> alphapapa.net>
Cc: eliz <at> gnu.org, 58431 <at> debbugs.gnu.org
Subject: Re: bug#58431: 29.0.50; [Eglot] Add "breadcrumb.el" feature based on
 imenu.el/project.el services
Date: Fri, 12 May 2023 14:09:09 +0100

On Wed, Oct 12, 2022 at 12:49 AM João Távora <joaotavora <at> gmail.com> wrote:

> Let's use some M-x artist-mode magic to explain what is in place
> and what I am proposing.
>
> +---+----+   +---------+     +----------+
> |eglot.el|   |python.el|     | ruby.el  |
> +---+----+   +---+-----+     +----+-----+
>     |            |                |
>     |            |                |
>     |            v                |
>     |        +----------+         |
>     +------->| imenu.el |<--------+
>              +-+--------+
>                |
> +--------------+
> |
> |  +-------------------+
> \->|which-func.el      |
> |  |(already working)  |
> |  +-------------------+

> \->|...                |
> |  +-------------------+         +--------------+
> |                                |  project.el  |
> |  o-------------------o         +--------------+
> \->|breadcrumb.el      |             /
>    |(proposed addition)|<------------
>    o-------------------o
>

I've now created https://github.com/joaotavora/breadcrumb with
exactly this architecture.  Suggest everyone interested
check it out.  Propose we add it to ELPA.  It is not
Eglot-specific so it needn't depend on Eglot (but I've tested
it with Eglot and it works well).


João

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

From: Yuan Fu <casouri <at> gmail.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: Adam Porter <adam <at> alphapapa.net>, Jeremy Bryant <jb <at> jeremybryant.net>,
 eliz <at> gnu.org, 58431 <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#58431: 29.0.50; [Eglot] Add "breadcrumb.el" feature based on
 imenu.el/project.el services
Date: Wed, 17 May 2023 14:31:14 -0700

> On May 12, 2023, at 6:09 AM, João Távora <joaotavora <at> gmail.com> wrote:
> 
> On Wed, Oct 12, 2022 at 12:49 AM João Távora <joaotavora <at> gmail.com> wrote:
> 
>> Let's use some M-x artist-mode magic to explain what is in place
>> and what I am proposing.
>> 
>> +---+----+   +---------+     +----------+
>> |eglot.el|   |python.el|     | ruby.el  |
>> +---+----+   +---+-----+     +----+-----+
>>    |            |                |
>>    |            |                |
>>    |            v                |
>>    |        +----------+         |
>>    +------->| imenu.el |<--------+
>>             +-+--------+
>>               |
>> +--------------+
>> |
>> |  +-------------------+
>> \->|which-func.el      |
>> |  |(already working)  |
>> |  +-------------------+
> 
>> \->|...                |
>> |  +-------------------+         +--------------+
>> |                                |  project.el  |
>> |  o-------------------o         +--------------+
>> \->|breadcrumb.el      |             /
>>   |(proposed addition)|<------------
>>   o-------------------o
>> 
> 
> I've now created https://github.com/joaotavora/breadcrumb with
> exactly this architecture.  Suggest everyone interested
> check it out.  Propose we add it to ELPA.  It is not
> Eglot-specific so it needn't depend on Eglot (but I've tested
> it with Eglot and it works well).

Looks good! It doesn’t seem possible for a major mode to give breadcrumb a custom “imenu-alist” that’s different from what it gives to Imenu? It might be useful because it’s common for major modes to add a category layer in the imenu alist, like Function > xxx and Class > xxx instead of xxx along; and there might be other reasons the major mode want the breadcrumb to be different from Imenu.

In general it might be useful for breadcrumb to have it’s own interface, with project and Imenu adapters come with it out-of-the-box.

Yuan

Previous Next

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