bug#73452: Code lens support in eglot

["João Távora" <joaotavora@gmail.com>]

On Tue, Sep 24, 2024 at 4:48 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Cc: 73452@debbugs.gnu.org
> > From: João Távora <joaotavora@gmail.com>
> > Date: Tue, 24 Sep 2024 15:26:55 +0100
> >
> > There is a discussion thread about this in the Eglot GitHub downstream tracker.
> >
> > https://github.com/joaotavora/eglot/pull/71
> >
> > The current consensus there is that the feature is not _that_ useful,
> > and that a clean implementation isn't really trivial since there is no
> > underlying Emcas support structure (like there is for documentation,
> > cross-referencing, diagnostics, snippets, etc)
>
> What infrastructure would be needed?

It's not easy to describe, you'd have to be very familiar with how
code lens work on VSCode and Visual Studio (I'm not).  It's a cross
between Flymake and Eglot's custom inlay hints.

The lower-level infrastructure (buttons, overlays, jit-lock-register) exists
and is probably enough for a decent experience (though there are
the typical annoying flaws with overlays and jit-lock-register).  The problem
is knowing how to tie this together in an sensible and robust infrastructure
that Eglot (or other providers) can plug into.  An abstraction that will model
something presumably more useful and practical than what is already
available through other existing Emacs means (vc-* commands, M-x compile,
Eglot code actions).  Read the last parts of the discussion I linked
to if you're
interested.

João