Language Client: Implement CodeLens

[bryphe]

CodeLens is helpful for languages that have inferred static typing, because it can help show the inferred types. This would have implications across the rendering pipeline (especially with Neovim integration).

[bryphe]

Adding a bounty - this would be a great feature to have from the LSP. I don't know too much about this feature, so if someone is interested in picking this up, we should work together to come up with completion criteria.

[hoschi]

Do you have a picture? I know only https://atom.io/packages/atom-lupa which has the backend as standalone npm package available btw.

[bryphe]

There's some documentation on how Visual Studio Code shows it, here

It looks like there are two parts;

• The references line above the code. We'd have to consider how to render this in Oni, since we do currently render based on the Neovim screen grid. We could potentially only show it on 'empty lines' and not need to adjust our rendering, or come up with some other rendering scheme for it.
• The hover that shows when you put your mouse over the code lens.

[hoschi]

Thanks, it is much clearer now. Nice thing to have, for sure.

[akinsho]

@bryphe I'm very curious about this functionality though as a longish time vim user have absolutely no idea re the what or why of this feature thought it does look fun, I've read the documentation you linked from vscode though tbh I'll admit to being a bit vague still, I've seen a vscode function complexity plugin and a git blame one which showed a git blame above a function which I assume is what this is sort of.

Given that this would be a biggish feature that would need to integrate with other plugins down the line I was wondering if you'd given more thought to how this might fit into oni. I think your idea re rendering it in empty lines sounds ? potentially easier though limits the entire codelens feature to a code block which might be fine?? (no idea having 0 experience with the feature how good or bad this would be) if it used something similar to the cursorPositioner I think theres gonna be a lot of visual noise unless the codelens somehow took priority over everything else.

Depending on how complex it's looking and time I've got available once syntax highlighting is done I thought id have a look at this if it seems manageable ^^, and that you weren't already planning on looking at this (think I'd rather have your implementation of this feature than mine 😆)

[bryphe]

Given that this would be a biggish feature that would need to integrate with other plugins down the line I was wondering if you'd given more thought to how this might fit into oni. I think your idea re rendering it in empty lines sounds ?

Definitely! I actually don't know that much about the feature yet - the information in the language server protocol is relatively vague: https://microsoft.github.io/language-server-protocol/specification

So I'm not 100% sure if the functionality in the screenshot is all due to the code lens, etc - it'd be interesting to test out a LSP with 'codeLens' functionality and see exactly what is returned in the CodeLens[] object, especially the data field.

I think this functionality would lend itself well to a buffer layer - as the buffer layer provides a way to render UI 'on top' of the existing buffer content, while being able to map from the text document position to the screen position.

So I could see a few steps:

• Create a BufferLayer like CodeLensBufferLayer, which takes a languageManager and the buffer as a dependency.
• The CodeLensBufferLayer could query the languageManager for codeLens by calling the sendRequest method, and set some React state to catch the result. It could potentially listen to buffer update events / enter events.
• The CodeLensBufferLayer would then render the 'codelens' in whatever scheme we decide - we could limit it to empty lines, code blocks, etc.

So in a sense this functionality would be isolated in the CodeLensBufferLayer, and be dependent on the editor (to add / register the layer), and also dependent on the languageManager (to send it requests).

As an aside, my hope is BufferLayer will be useful for all kinds of visual augmentation. I started moving a little bit of our LSP functionality there (the Definition and Errors are in buffer layers now). I could see us, in the future, having a bunch of other functionality in BufferLayers too - like showing git/VSC info, colors alongside hex values in CSS, etc.... lots of possibilities, since they can do everything from render over the entire buffer (like the welcome experience) to render markers for specific tokens, etc.

I hope that helps give you some ideas, thanks for running them by me. Let me know if you have any other questions!