bug#73452: Code lens support in eglot

[Eli Zaretskii <eliz@gnu.org>]

> From: João Távora <joaotavora@gmail.com>
> Date: Tue, 24 Sep 2024 22:01:02 +0100
> Cc: federico.beffa@fbengineering.ch, 73452@debbugs.gnu.org
> 
> > 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).

Then maybe someone could describe such an abstraction.

> Read the last parts of the discussion I linked to if you're
> interested.

I did, but couldn't answer my questions, because the discussion relies
heavily on VSCode features with which I'm not familiar and whose
descriptions I saw didn't clarify the issue.