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

Previous Next

Package: emacs;

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

Date: Tue, 11 Oct 2022 09:17:01 UTC

Severity: wishlist

Found in version 29.0.50

Full log


View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: 58431 <at> debbugs.gnu.org
Cc: eliz <at> gnu.org
Subject: bug#58431: 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.













This bug report was last modified 2 years and 91 days ago.

Previous Next


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