Integrate OCaml/ReasonML language server

[bryphe]

Language server here: https://github.com/freebroccolo/ocaml-language-server

Wanted an excuse to learn more about these languages 👍 👍

[jordwalke]

In the ReasonML Discord channel, we consistently hear overwhelmingly positive feedback about @freebroccolo's VSCode plugin and language server.

[keforbes]

Moving back to 0.3 since 0.2.5 was released without this getting merged in, #488. :stuck_out_tongue:

[bryphe]

Merged in the ocaml-language-server integration, since that was blowing up (and most of it was really not specific to ocaml/reason, but just extending out the language server protocol support - since ocaml-language-server is the most complete implementation I've used so far).

A few remaining items I'd like to look at before closing this:

• Snippet integration (on par with what is supported in VSCode)
• refmt integration (or indentation support from ocaml-language-server)

• 533 - add support for DiagnosticSeverity.Warning

There are also some longer-term items I'd like to look at, potentially outside the scope of this item, like:

• Integrated playground (this helped me a lot testing out reason & ocaml + bucklescript)
• Moving some other Oni components to Reason, including some UI components. (For example, modularing out the QuickOpen experience and implementing as a reason-based plugin). I'd like for Oni to have a first-class Reason experience, on-par or beyond the TypeScript support.

[dvisztempacct]

Hi.

My team and I are trying to flesh out our tooling for ReasonML development.

We've used vim, neovim, atom, vscode, and now oni!

I wanted to take a crack at integrating ocaml-language-server formatting for Oni, but since I saw this issue has been open for a while, I thought I'd ask here what's holding it up, or if you have any specific idea about what a good or bad approach might be.

I've had some experience hacking on the same integration for nvim using languageclient-neovim and ocaml-language-server, but from skimming through Oni's source code it seems like you guys are into vscode-languageclient, and maybe that has something to do with the slow movement here?

Let me know!

[akinsho]

@dvisztempacct I think the main hurdle here is that there are quite a few bits of LSP functionality that our ls client doesn't handle yet like formatting, code actions etc. I don't think the vscode client is a particular hurdle (@bryphe) can answer this best but I think it's just an outstanding bit of work which @bryphe started to look at in #974 and #1326 so if you were curious about looking at that I think those PR's would be a good place to start