Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tooling support #41

Open
leostera opened this issue Jan 21, 2021 · 4 comments
Open

Tooling support #41

leostera opened this issue Jan 21, 2021 · 4 comments
Labels
question Further information is requested tooling Build system plugins and other tools tracking

Comments

@leostera
Copy link
Owner

leostera commented Jan 21, 2021

We'll need things like:

Formatting

Calling caramel fmt should reformat all inputs.

Doc Generation

Calling caramel docs *.mli *.rei --output ./docs should create docs from those interface files.

Language Server

What I'm considering atm is bundling Merlin within Caramel, so we have control over the subset of the language being accepted.

Calling caramel language-server should be the equivalent to booting a Merlin daemon, and we'll need a way to create the right .merlin files as well, possibly through a separate command that can be properly guided by a build system (e.g. caramel language-server setup ./path/to/lib/a ./path/to/lib/b ...)

REPL

TBD

@leostera leostera added question Further information is requested tooling Build system plugins and other tools tracking labels Jan 21, 2021
@nicobao
Copy link
Contributor

nicobao commented Jan 26, 2021

Language Server

[...]

Calling caramel language-server should be the equivalent to booting a Merlin daemon, and we'll need a way to create the right .merlin files as well, possibly through a separate command that can be properly guided by a build system (e.g. caramel language-server setup ./path/to/lib/a ./path/to/lib/b ...)

Besides the fork of Merlin, we'll also need our custom language server supporting the standard MS protocol (and running Merlin behind be scene to do the hard work, as you suggested!)
I suppose we can fork either Erlang LS or OCaml LS, or even Elixir LS which is more mature, and work on that. It's a shame that Erlang LS/Elixir LS don't rely on a shared library implementing a language agnostic LSP.

I guess the biggest challenges will be:

  • customizing Merlin with our custom syntax
  • supporting interop with at least Elixir and Erlang at the source code level
  • handle multiple build systems (rebar3, mix but also, opam/dune?). For that feature, we can eventually use the Build Server Protocol (it is used in Scala LSP for instance)

@leostera
Copy link
Owner Author

I've been looking more into the ocaml-lsp project and I think it makes most sense to vendor since it already comes with Merlin vendored as well.

On top of this, we may get away by submitting a patch to the vscode-ocaml-lsp plugin that makes the actual lsp binary path configurable so it points to caramel lsp instead. I can't promise it'll be that easy, but it can't be that hard 🙌🏽

@nicobao
Copy link
Contributor

nicobao commented Feb 12, 2021

Yes!
We might benefit from looking into that project: https://github.com/axelson/ls_proxy
@axelson recommended it ^^, he's the maintainer of elixir-ls

@axelson
Copy link

axelson commented Feb 13, 2021

I'd love to collaborate on LSP Proxy! It's a bit rough around some of the edges but it can be very helpful in understanding all of the messages that are going back and forth between the server and client.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested tooling Build system plugins and other tools tracking
Projects
None yet
Development

No branches or pull requests

3 participants