Microsoft Language Server Protocol about oni HOT 9 CLOSED

Also, just in case you haven't seen it: neovim/neovim#5686 This is pretty cool.

from oni.

Hi TJ! Thanks for the kind words and checking this project out :)

Great point, I agree 110% - the protocol makes a lot of sense to implement. Actually the language extensibility features for VSCode were a major inspiration and driving factor - the interfaces I have so far are pretty similiar because of that, and I think mapping to the language service makes a lot of sense. Will be way easier to add the language features by these already-written services.

I actually tried really, really hard to like VSCode and use it (plus the vim plugin here: https://github.com/VSCodeVim/Vim) but there are just enough gaps that it still is problematic, and there are also features I would like to see in the editor that unfortunately their API surface is not quite extensible enough to implement, but this project takes a lot of inspiration from VSCode (and Atom and LightTable). It's a great editor though and there is a ton of momentum around the plugins and supported languages - so it'd be great to leverage that.

I took a look through your repo and it's really helpful. I didn't realize how well the language service protocol is documented, and you've done extensive work in hooking up to it via the async capabilities. Really clean and easy to follow implementation, too. Awesome to see work being done on that - that potentially benefits everyone using neovim, including users who don't want a UI version.

In the context of this project, I'm trying to writing as minimal VimL as possible (JS / TS with the language features in the editor, debugger, etc is just more fun to work on and maintain for me :) ) - but I think that it would be possible to hook up to the language service protocol directly when we load plugins in browser/src/Plugins/Plugin.ts & PluginManager.ts - would just need some sort of shim/adapter layer, as the protocol being used is pretty close. Or maybe even just pivot to use their protocol.. If you're interested in collaborating on that, let me know

from oni.

And that UI looks awesome! It's really cool to see the work being done with neovim and the scenarios it is enabling. I opened #9 to track integrating with the external popupmenu as a starting point/proof of concept

from oni.

So one thing I'm working on that might help you a lot is making an api to handle responses for the language server protocol. The idea would be something like this:

1. User initiates some LSP (language server protocol) request
2. You do all the communication to some language server to get the information
3. You now have the response from the LSP. You have to decide what to do with it. This is where I think the nvim api would be useful. You would...
4. call langserver#api#textDocument#definition(response_dictionary, options)
5. The language server shim would handle the response and do all the neovim required items (managing a buffer, go to line, etc.)

This way you don't have to worry about keeping track of what happens in response to certain items and people don't have to duplicate work (because we would have to do the same thing, in essense.)

Does that make sense?

Another thing I want to add is the ability to make a request, and then have a custom callback attached to it. So you might want to initiate a request for a hover (https://github.com/Microsoft/language-server-protocol/blob/master/protocol.md#textDocument_hover). Well I already have a function for doing that (https://github.com/tjdevries/nvim-langserver-shim/blob/master/autoload/langserver/hover.vim#L19, although I would add this to the API with easily discoverable names... just haven't yet 😄 ). So you could call that function and add a callback for you to handle the response (since you'd do hover differently than regular neovim would, since you have fancy and pretty gui features).

Let me know if you have any questions about this. Most of these thoughts are still bouncing around in my head. The main goal would be that lots of GUIs / plugins would like to make use of the LSP within Neovim, so it'd be good if we could centralize all the knowledge and solve the difficult problems in just one place, instead of everyone having to do it over and over.

THanks for your time. 😄

from oni.

Thanks for taking the time to drill into details :) I really like the work you've done and you're thinking around centralizing the knowledge / not re-inventing the wheel.

My hesitation in terms of doing a deeper integration between this project and a VimL language server API layer stems from one of the goals I have in mind for the project:

Rich plugin development - using JavaScript, instead of VimL, allowing deep language integration.

And to be fair, this is partly for selfish reasons - I personally hate debugging and writing VimL :) But I also believe there is a ton of value in JavaScript - even though it's not a perfect language by an stretch, there's a huge ecosystem and continual investment in tooling - and many of the modern editors like Atom, VSCode, went this route, and have been hugely successful in creating a vast ecosystem of high-value plugins. So I'm hoping that Oni could tap into that as well, and combined with the power of Neovim, could be a truly productive, modern (even next-gen), modal editor.

For those reasons, I would prefer not to call into a VimL layer to implement the language service abstraction, and instead implement it in the JS layer to align with the vision of the project.

However, there is a ton of value in your project and in general to have the language server layer accessible in Neovim, and not just Oni - it allows terminal users to get the benefit of the language services, which is huge! Oni is essentially ignoring that need because it doesn't run in the terminal, so it is a departure from a large part of the vim/neovim audience - but your plugin addresses that gap.

from oni.

Thanks for the reply.

I think I understand your concerns. The main reason I suggest using a VimL layer to people is to manage many of the built-in features that neovim already has. For example, in a goto situation, you would want to manage the jump-list (or tag-list, depending on how you want to view it) well so that you can do either a <c-i> or <c-t> to move back to the original place before the movement. I think VimL is good at managing these items and having a place where it's managed centrally would reduce a lot of work.

But I definitely understand the distaste for VimL, it certainly has some interesting quirks haha 😄.

My thinking would be to just use the VimL for places where the VimL is suited and do everything else in Javascript. In fact, I would recommend definitely using the vscode's javascript language server protocol client / server (https://github.com/Microsoft/vscode-languageserver-node) because it will most likely be faster and easier to use. It seems you are already interfacing a lot with VimL (you have several "built-in" vim plugin), so I think considering using the langserver-shim as another vim plugin to handle some of the more internal Neovim actions, rather than the GUI side items.

So in case I wasn't clear, steps 1 through 4 would be in javascript. The only thing that would happen in Viml is the handling of the response received from the server.

Anyways, I'm obviously just being selfish as well, cause I want people to use my project ;) Thanks for the convo, it's giving me some new ideas to implement.

from oni.

@tjdevries: you seem to have a decent amount of knowledge on the subject. After we hijack VSCode's implementation and use it for our own nefarious purposes, would we just have the gui act as a sort of middleman between langserver and your shim?

from oni.

Initial LSP support is now in Oni - a reference plugin leveraging the language client is available in the oni\vim\core\oni-plugin-csharp.

As mentioned in the PR, have several follow up issues being tracked (additional functionality, additional out-of-the-box language support, etc):
#382 #381 #380 #379 #378 #377 #376 #375

from oni.

Closing as the core implementation is complete - tracking remaining work in other issues.

from oni.