Language Server Implementation (LSP)

[tjdevries]

@justinmk, I have been looking into trying to write some sort of shim/plugin/client (still not sure what the name should be) to provide (at least some amount of) integration between the language server protocol and Neovim.

I have read your discussion in Gitter a bit ago and it got me interested in trying to implement some part of it. However, before I got working on implementing it, I wanted to try and figure out if I was understanding the idea of the integration correctly.

I made this diagram to explain some of what I was thinking. Obviously there are a lot more scenarios to cover, but this is what I was thinking.

Also, do you know what language this client should be written in? I was thinking one of the remote plugins. It appears that Microsoft is working with this (https://github.com/Microsoft/vscode-languageserver-node) for a lot of their stuff, and we might be able to use it as well. Do you know which of the neovim node libraries would work well with this?

Thanks.

[KillTheMule]

Awesome, this things seems to be getting traction: https://internals.rust-lang.org/t/introducing-rust-language-server-source-release/4209.

[tjdevries]

Yeah, it looks like there are several implementations coming along quite nicely (https://github.com/Microsoft/language-server-protocol/wiki/Protocol-Implementations). I think this would be a pretty killer feature for neovim.

[justinmk]

The node implementation would be a good start. A lua implementation could be shipped with Neovim later.

[tjdevries]

Here's where I'll be working on this: https://github.com/tjdevries/nvim-langserver-shim

I will try and make it so we can swap out the remote plugin later (so get a lua implementation when a SDK for the language protocol is available).

[euclio]

cc #4982

[tbelaire]

Just to note, I had started on a python client with the intent of then writing vim and neovim, and making sure I can support the Rust LSP.

[purpleP]

Not sure that this is the right piece for it, but I have this idea for a while.

If there would be a thing that would take a language specification (BNF etc) and make a parser for that language (should be totally possible and there is YACC).

The parser can generate AST and it should be possible to create a DSL for linting rules, so that not only linter designers could write them but users too. Which would solve a problem where pylint (python linter program) would complain in wrong places and won't where it should have been.

This tool should have integration with editors similar to what Microsoft proposes.

This would give smarter completions that take types (possibly inferred for dynamically typed languages) into account.

Next thing is refactorings. Because refactoring is just a function from one AST to another it should be possible to create fairly simple DSL or service for that also. So language specific refactorings could be added easily.

This thing could also remove the need of ctags as it could store all information about various program components (like classes, variable names etc) in some database like sqlite, mongo etc) and where ctags gives you ability only to jump to tag that is for the word under cursor this thing could integrate with Unite plugin and show things like all classes or all variables or all strings etc (more complex queries).

[tjdevries]

If I'm understanding correctly, that's pretty much a language server as defined by microsoft's protocol.

[justinmk]

If there would be a thing that would take a language specification (BNF etc) and make a parser for that language (should be totally possible and there is YACC).

Check out the scintillua project for a library of PEG grammars for various languages. I'd really like to see this used for syntax highlighting in Nvim.

Because refactoring is just a function from one AST to another it should be possible to create fairly simple DSL or service for that also.

Refactoring is not AST => AST. Useful refactoring depends heavily on semantic analysis (type system) or more sophisticated inspection.

This thing could also remove the need of ctags as it could store all information about various program components

Microsoft Language Server Protocol abstracts those things into a common interface (this could be the DSL you mentioned) that can be used by any front end. AFAIK it is not a one-size-fits-all solution for storing, indexing, querying.

[purpleP]

@justinmk As I've said type checker will be also implemented in my proposed solution. And ANY code change is AST -> AST and so is refactoring. As to scintilla it only have lexer, right? Whereas I'm talking about parser.

[purpleP]

@tjdevries I've read briefly about Language Server. It differs from my idea in two ways. First I'm talking about implementation and protocol, whereas MLS is only a protocol. Second, in my solution protocol differs a bit. For example MLS doesn't define any means of querying the code base. Only jump to definitions. But I could be wrong about it.

One of the reasons I'm talking about this is that my proposed solution could be compatible at least partially with MLS, so if neovim would support that it would be good.