4 ms·

Look at https://microsoft.github.io/language-server-protocol/ https://microsoft.github.io/language-server-protocol/ for more info. It's a standard interface IDE

Look at https://microsoft.github.io/language-server-protocol/ https://microsoft.github.io/language-server-protocol/ for more info. It's a standard interface IDEs can use for things such as autocomplete rather than every IDE having to reinvent the wheel.

int_19h 8y ago
To add to this: the beauty of the protocol is that it uses JSON over stdin/stdout for communication. So if your language can make console apps, you can write a language server in it that works with any compliant editor/IDE - no FFI necessary, no need to learn how to author extensions for that editor etc. And, conversely, if your editor/IDE can fork a child process and redirect its standard streams, you can support any language server and not care about how it's implemented. I think this more than anything else has contributed to its rapid adoption, especially on Unix-likes.
- hawski 8y ago
  Why was this downvoted? Is it not factual? If it's not, it would be far more helpful if it would be pointed out. If it's implemented as stated by int_19h then it's my favourite interface - stdio instead of FFI. So one could implement a server even in Brainfuck.
  - int_19h 8y ago
    The protocol itself is transport-agnostic - it just needs a bidirectional stream, and the spec doesn't define what it is. In practice, both stdin/stdout and sockets are used - the latter usually for language servers that are "heavyweight", such that it is advantageous to spin up the server once, "prime" it (let it do any indexing etc), and then reuse it between concurrent sessions. The standard streams are usually the default choice for simplicity reasons, though. Implementing a server in Brainfuck is theoretically possible, but only if you ignore the heat death of the universe as the upper time boundary. ~
justaj 8y ago
Interesting, I wonder if Vim is able to use this protocol as well.
- oblio 8y ago
  Look up vim lsp plugins.
- int_19h 8y ago
  https://github.com/prabirshrestha/vim-lsp https://github.com/prabirshrestha/vim-lsp https://github.com/autozimu/LanguageClient-neovim https://github.com/autozimu/LanguageClient-neovim

int_19h 8y ago

To add to this: the beauty of the protocol is that it uses JSON over stdin/stdout for communication. So if your language can make console apps, you can write a language server in it that works with any compliant editor/IDE - no FFI necessary, no need to learn how to author extensions for that editor etc. And, conversely, if your editor/IDE can fork a child process and redirect its standard streams, you can support any language server and not care about how it's implemented. I think this more than anything else has contributed to its rapid adoption, especially on Unix-likes.

hawski 8y ago
Why was this downvoted? Is it not factual? If it's not, it would be far more helpful if it would be pointed out. If it's implemented as stated by int_19h then it's my favourite interface - stdio instead of FFI. So one could implement a server even in Brainfuck.
- int_19h 8y ago
  The protocol itself is transport-agnostic - it just needs a bidirectional stream, and the spec doesn't define what it is. In practice, both stdin/stdout and sockets are used - the latter usually for language servers that are "heavyweight", such that it is advantageous to spin up the server once, "prime" it (let it do any indexing etc), and then reuse it between concurrent sessions. The standard streams are usually the default choice for simplicity reasons, though. Implementing a server in Brainfuck is theoretically possible, but only if you ignore the heat death of the universe as the upper time boundary. ~

justaj 8y ago

Interesting, I wonder if Vim is able to use this protocol as well.

oblio 8y ago
Look up vim lsp plugins.
int_19h 8y ago
https://github.com/prabirshrestha/vim-lsp https://github.com/prabirshrestha/vim-lsp https://github.com/autozimu/LanguageClient-neovim https://github.com/autozimu/LanguageClient-neovim