Language Server Protocol Proposal

[sphaerophoria]

Proposal for Language Server Support

I've been working on my own plugin atom-rtags-plus for a bit now and am fairly happy with the functionality. Unfortunately I've found that when working in other languages it's frustrating that each plugin has a separate set of keybindings and feature sets that need to be configured independantly. Most of the languages I write in have at least partial support for the language server protocol and I'd love to leverage that to write something that provides a consistant interface and feature set.

Protocol intro

The protocol is defined at https://github.com/Microsoft/language-server-protocol/blob/master/protocol.md but I'll sum it up here to the best of my understanding.

Servers and clients communicate with JSON-RPC over any type of socket (can use unix io or tcp etc.). Communication is bi-directional with the ability to push commands in either direction.

I've only done a quick onceover of the api, but it seems to support most of the major functionality provided by rtags.

• code completion
• diagnostics
• code navigation
  • I believe virtual support could be achieved through goto definition/references
• Any unsupported actions can be worked around by going out of spec
  • clients could register for support for an rtags/ subset of commands that we would have full control over

Benefits

• Free UI implementations (eclipse, vs code, see http://langserver.org/ for more)
• Less friction when switching between languages and editors
• Potentially involved refactoring could better support for current diverging code
• Potentially more exposure as there is not currently a complete language server for c/c++. Most of the work has already been done in RTags, we just have to hook up the interface

Drawbacks

• Potentially more maintenance as changes would now need to test LSP in addition to JSON,Elisp,stdout
  • This already seems to get broken fairly frequently, so this set of changes could potentially make that problem even worse

Proposal for a Potential Implementation

• RDM spins up another socket connection alongside TCP/Unix/etc. in Server::initServers

• Requests to this socket will be translated from LSP messages into RtagsMessages

• We can add a query flag to signal that we want LSP output opposed to stdout, elisp, or json

• Each job in it's current state will have to support LSP messages directly

  • I've noticed while working on atom-rtags-plus that the current printing mechanism is a little less than optimal
  • each job needs to support all output types (elisp, json, stdout, and now LSP)
  • I would like to propose some sort of generic serializer (ideally still stream based to avoid ram usage increase)
    • Rtags data structures mostly seem to be hierarchical with a key-value setup
    • Any job that isn't currently key value could be modified to be key value fairly easily, one job at a time
    • serializer interface could look fairly simjple
      • serializer.open()
        • resolves to indent on stdout
        • resolves to { in json
        • resolves to ( in elisp
      • serializer.close()
        • resolves to outdent on stdout
        • resolves to } in json
        • resolves to ) in elisp
      • serializer.key(string)
        • inserts key: stdout
        • unfortunately my elisp falls apart here, i believe we could insert "key . "
        • if the keys for LSP need to be different we can have a mapping of rtags keys to LSP keys
      • serializer.value(string)
        • inserts the data
        • can format data based on key type and serializer type
      • I'm not sure if a list/array api is needed but I don't think it would be that difficult
    • this would hoepfully reduce breakages accross the different output formats and reduce code duplication (and complexity) accross the Job implementors

• I believe this is better than doing an external proxy because

  • programatically parsing the rc output and converting it to LSP is overhead (in developer time) that could be avoided
  • I think it could slightly help adoption not having to get yet another server

What do you think? I'm only casually familiar with the Rtags code base as well as LSP so I may have missed some details. Is this something you'd be interested in PRs for?

[Andersbakken]

Hi

Sorry about the delay. I've been kinda swamped. I think the proposal sounds good and would definitely be interested in a PR around this. I wouldn't mind generalizing the output formatting and the translation from JSON-RPC to RTagsMessage is the same mechanism I would choose. Looking forward to the PR.

Thanks

[sphaerophoria]

Cool, thanks for the input. Hopefully I'll get some time to prototype out a simple prototype during the week.

[Barricade]

Any update on this?