GNU bug report logs -
#73452
Code lens support in eglot
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
On Thu, Sep 26, 2024 at 4:35 PM Federico Beffa <
federico.beffa <at> 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
[Message part 2 (text/html, inline)]
This bug report was last modified 256 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.