Moving the codelenses to be above the function? #727
Replies: 5 comments 4 replies
-
Yeah. We should probably add a feature to Kakoune to allow showing virtual text in a separate line above the cursor. Until then we could show it after the newline character (using the new One workaround is to not use inlay code lenses, instead use |
Beta Was this translation helpful? Give feedback.
-
Yeah. We should probably add a feature to Kakoune to allow showing virtual text in a separate line above the cursor.
Until then we could show it after the newline character (using the new
`flag-lines -after` highlighter from latest Kakoune master). That would be
a simple change. Of course it completely ignores the column specified by the
server but if it works for current use cases and is not meant to be permanent,
I guess why not.
I think showing it after would work great!
One workaround is to not use inlay code lenses, instead use `l` in lsp mode to
display them on demand. But that's probably less convenient, especially because
we don't have a way to move to the next code lens yet - though that's something
we want regardless, something like `lsp-object code-lens`. Also `lsp-hover`
probably might show the type info already, I haven't tried with OCaml recently.
Yeah, at the moment I have inlay code lenses disabled and just look at the info from
lsp- hover, which includes the type signature. It works, but code lenses are very
nice with OCaml, where you very rarely explicitly add the type but let the type
inference handle it for you.
|
Beta Was this translation helpful? Give feedback.
-
On Tue Feb 27, 2024 at 8:09 AM CST, Johannes Altmanninger wrote:
do you have a minimal ocaml example that shows code lenses?
I get code actions and diagnostics from ocamllsp but no code lenses
Makes sense, the feature is disabled by default.
Here is my config
```
[language_server.ocamllsp]
filetypes = ["ocaml"]
# Often useful to simply do a `touch dune-workspace` in your project root folder if you have problems with root detection
roots = ["dune-workspace", "dune-project", "Makefile", "opam", "*.opam", "esy.json", ".git", ".hg", "dune"]
command = "ocamllsp"
settings_section = "_"
[language_server.ocamllsp.settings._]
codelens.enable = true
```
|
Beta Was this translation helpful? Give feedback.
-
that works. Maybe we should enable that by default?
My guess is that that's what VSCode does, which would mean there is little pressure on ocamllsp to pick good defaults.
So that's why we need to do that.
I think if we resolve the issue then absolutely, it would be trivial to disable it too by overwriting the config should the user want to.
One question is, is the default integration (without inlay code lenses) a net positive? It shows a `>` in the gutter and by running `:enter-user-mode lsp <ret> l` you can see the type names.
Given that you already see it with the hover-info, I don't think it adds too much. It can even be a bit confusing as it shows them as autocomplete options.
|
Beta Was this translation helpful? Give feedback.
-
I've pushed 053dde5 to show inlay code lenses after the line.
It requires Kakoune >= 2024 which is not released yet, so I recommend you build it from source (it's very easy)
I'll try to get around to compile it from source and try it out. Thank you so much again for all the excellent work! kak-lsp is my best LSP experience so far. :)
|
Beta Was this translation helpful? Give feedback.
-
Heya!
Thanks for all the amazing work, kak-lsp is an absolutely fantastic experience.
Recently I've been trying out ocaml with LSP support, and it has codelens support. However, displaying it inlay is.... not very pleasant as the actions are next to the function.
Is it possible to place the code leneses above or right of the function? Here is a picture of what it looks like atm
The type signatures are so long that it becomes impossible to read.
Beta Was this translation helpful? Give feedback.
All reactions