Language Server Protocol

[Neil Hodgson]

The Language Server Protocol is a way to provide features like file checking and calltips to editors and IDEs for a variety of programming and document languages. Each language has its own server that can be used from different editors. Each editor only has to implement a generic method for all the languages instead of making each language work.

The features that may be provided by a language server include populating autocompletion lists, providing function signature information for calltips, displaying inline warnings from compilers and linters, and showing where an identifier is defined or where that identifier is referenced.

Microsoft’s Visual Studio Code is currently the main user of language servers and it comes bundled with several. Other editors are implementing the protocol and language communities are working on servers for their languages.

It would be great for SciTE and other Scintilla-based editors to implement LSP. It may be possible to share some implementation code between projects. LSP is based on JSON-RPC (http://www.jsonrpc.org/specification) and there is an MIT-licensed C++ library for JSON-RPC at https://github.com/cinemast/libjson-rpc-cpp . Most of Microsoft’s servers are written in TypeScript which compiles to JavaScript while others have been implemented in and for Java, Go, PHP, and Rust.

https://code.visualstudio.com/blogs/2016/06/27/common-language-protocol
https://github.com/Microsoft/language-server-protocol

Protocol reference:
https://github.com/Microsoft/language-server-protocol/blob/master/protocol.md

List of language servers:
https://github.com/Microsoft/language-server-protocol/wiki/Protocol-Implementations

[Valentin]

Hi Neil,

just a little idea: there is an (outdated but propably updatable) Lua
implementation of JSON-RPC (based on LuaSockets):
https://github.com/craigmj/json4lua

So maybe a rather simple solution for SciTE could be to load a lua-based
LSP client into SciTE on start up, and then let it control SciTE based
on results received from the server, either using the Lua
SciTE-Pane/Scintilla API or raw win messages?

Valentin

[Neil Hodgson]

Valentin:

> just a little idea: there is an (outdated but propably updatable) Lua
> implementation of JSON-RPC (based on LuaSockets):
> https://github.com/craigmj/json4lua
>
> So maybe a rather simple solution for SciTE could be to load a lua-based
> LSP client into SciTE on start up, and then let it control SciTE based
> on results received from the server, either using the Lua
> SciTE-Pane/Scintilla API or raw win messages?

Possibly. Having core features implemented in Lua makes it more likely that a scripting mistake will disrupt those features. Allowing Lua scripts to query an LSP would be great for exploring new features as LSPs evolve.

Neil

[Valentin]

Neil Hodgson wrote:
> Having core features implemented in Lua makes it more likely that a scripting mistake will disrupt those features.

Good point. But I guess at least complete disruption/exit of the LSP
related stuff could be prevented by wrapping everything into a pcall:

local quit = false
while not quit do pcall(function ()

-- all LSP related code here

end) end

Then any error would disrupt the current call, but the client then
immediately would be started again.

Valentin

[Thorsten Kani]

...wow - didnt know about - thanks for that pointer !