Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The specification should maybe say where code lenses are shown in the client #1558

Open
michaelpj opened this issue Oct 3, 2022 · 6 comments
Labels
code lens feature-request Request for new features or functionality help wanted Issues identified as good community contribution opportunities
Milestone

Comments

@michaelpj
Copy link
Contributor

At the moment, the specification says nothing about how code lenses are displayed. In all the existing implementations that I know of, code lenses are displayed inline in the code using the title of the command to provide the text. But there is not agreement about where they are displayed! For example, VSCode shows them above the target line, and recent lsp-mode shows them at the end of the target line.

This is quite important: since code lenses appear in the code, how they are interpreted by the user depends on where they appear!
For example, the Haskell language server provides code lenses that show the type signature for functions that do not have one, inserting them on click. This works perfectly when the code lenses appear above the line, but look very weird if they appear at the end.

So it would be good if the specification could provide some guidance for server implementors. Even if the guidance is "you should not make any assumptions about where or whether code lenses are displayed" that would be very useful: then we would know that what we are doing in HLS is making wrong assumptions and we should stop! Basically I would like to know whether it's HLS or the lsp-mode maintainers who are doing something wrong :)

@ericdallo
Copy link

ericdallo commented Oct 3, 2022

Example of lens on the end of the line on clojure

2022-10-03_14-19

@rchl
Copy link
Contributor

rchl commented Oct 3, 2022

Don't know if it brings anything to the table but FYI, Sublime Text has two ways of showing Code Lenses. One that places code lens under the relevant code and one that places it at the far-right of the line:

https://lsp.sublimetext.io/features/#code-lenses

IMO both work for the case pictured there at least.

@ericdallo
Copy link

BTW It's pretty common to see line flicker on vscode/emacs when code lens are above, but not on emacs when code lens are far-right

@olegtk
Copy link
Member

olegtk commented Oct 3, 2022

I think it's pretty fundamental LSP principle that servers don't control client UI so the guidance should indeed be "you should not make any assumptions about where or whether code lenses are displayed". It's basically implied, just like with any other feature like completion or code actions.

@dbaeumer
Copy link
Member

dbaeumer commented Oct 4, 2022

I agree with @olegtk that the specification should not suggest any you implementation. What we could do is the following:

  • add a client capability that informs the server of where the client shows code lenses (e.g. above, below, far right, right, ...)
  • if the capability is missing then "you should not make any assumptions about where or whether code lenses are displayed" is implied.

@dbaeumer dbaeumer added feature-request Request for new features or functionality help wanted Issues identified as good community contribution opportunities code lens labels Oct 4, 2022
@dbaeumer dbaeumer added this to the Backlog milestone Oct 4, 2022
@michaelpj
Copy link
Contributor Author

michaelpj commented Oct 4, 2022

Or maybe if servers want to make assumptions about location they should use inlay hints now. I don't know whether inlay hints can replicated the "display on line above" behaviour of code lenses in vscode, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code lens feature-request Request for new features or functionality help wanted Issues identified as good community contribution opportunities
Projects
None yet
Development

No branches or pull requests

5 participants