On Thu, Sep 26, 2024 at 4:35 PM Federico Beffa <federico.beffa@fbengineering.ch> wrote:
> You may not like the VSCode UI, but Emacs doesn't have to use exactly the same interface. The client decides how to present the code lens text, and you may choose to only display it in some circumstances.
Like Eli said: design and _fully_ specify a model of user interaction with this feature and present it.
Doesn't have to be a funcional prototype, a mockup of some sort will do, as long as it is specified enough for future implementers to understand edge cases.
I.e. it's not enough to say "I want this thingy here like VSCode". Think
what happens if text is inserted before, inside or after, the locus of the
"code lens" annotation (if any). What happens if the text is deleted. What
conditions, if any, lead to invalidation of the lens's information and what happens
on said information. Anticipate the all-too-frequent "this thing flickers and its
annoying" complaint and how to possibly deal with it. How it should work (if
at all) in non-GUI Emacs. All of that is work that needs to be done, you don't
need to be an Emacs/Eglot wiz. I personally don't see enough motivation to
do it. I had for inlay hints, and I had to answer all those questions before
implementing it.
> Code lenses are part of the core features of LSP since several years and are used by many servers. If Emacs ignores them, all those features are not available in Emacs.
From what I was able to gather from other's reports , these features are already available
to users in one form or another. Indeed, the examples you show here could all be done
with code actions.
João