Language Server: more than formatting

[dpren]

This relates to discussion from https://github.com/avh4/elm-format/issues/194 about providing an AST for other tools to consume. But a step further.

Elm-format today is essentially a language server that just does formatting. I'd like to propose evolving elm-format in the direction of a more fully-featured, common language server. There are lots of ways to go about this. So I'll just present what, from my perspective, seems like the best route. (sidenote: I'm willing to do the necessary legwork of whatever I'm talking about here)

---

Why a language server?

• Performance. Complicated IDE type queries don't scale in most editor plugin environments.
• Centralize development effort:
  • reduces work
  • improves quality accross the board
• Endures over time

---

A possible vision:

1. Perhaps fork elm-format or copy parts into a new repo.

2. Rewrite or upgrade the existing parser's capabilities.

   I've mentioned on discourse my interest in developing error-tolerant parsing. This is my main focus. Consolidating parsing so there's at most just elm-compiler and one good IDE parser running at any given time.

   A question for the core team: Could elm-compiler output project-wide metadata to the disk?

   With cached info for every module, the language server would only have to worry about parsing active files.

3. Start adding features.

   How should it communicate with editors?

   One way is for the language server to just be a generic information center that other tools can query however they please. This offers flexibility.

   But I'm going to put forth an argument for using the Language Server Protocol.

---

Why the Language Server Protocol?

The idea is that most common IDE features are language agnostic in terms of UI.

This provides the opportunity where:

• Languages can share one backend implementation with many editors.
• Editors can share one frontend implementation with many languages.

So this means that most of the (client) plugin work is already done in all the commonly used editors. Plugins simply extend their editor's respective implementation. Here's an example of what that looks like in Atom: https://github.com/atom/ide-typescript/blob/master/lib/main.js which extends: https://atom.io/packages/atom-ide-ui

A Haskell LSP library already exists.

Will this limit the flexibility of plugin authors?

LSP is extensible:

• Custom elm-specific features can be added at any time.
• Plugins can subscribe to whatever features they want.
• Servers can choose to not implement extraneous features in the LSP spec.
• And again, LSP deals with just language agnostic features that don't demand a bespoke Elm-brand UI.

[avh4]

Implementing LSP seems outside the scope of elm-format, but I would expect that elm-format should be a useful piece that an LSP implementation could be build on top of. I think improving the parser is appropriate work that I would be happy to see included in elm-format. (Also, if it makes sense to separate the parser into a separate library that both elm-format and an LSP could use, I think that would make sense too.)

To summarize, I think elm-format should remain focused on 1) formatting, and 2) converting between Elm course code and an AST format. But I happy to accept improvements to elm-format's parser, and/or refactor elm-format to support other projects using it as a library.

[dpren]

I agree.

I wouldn't really care if the parser lives inside or outside the elm-format repo, just as long as it can be exposed separately. Reason being, an LSP would want to manage the parser state and formatting/render calls separately on its own terms.

Did you have a concrete plan for #109 yet? I think skipping erroneous top-level declarations is a good place to start. But I'd like to try and take it further to the level of sub-definitions or even expressions. This would be especially beneficial to other features like autocompletion.

Would you be open to potentially major changes to the parser from me, so long as it doesn't break anything? The recovery and incremental parsing features that I have in mind would require porting to Megaparsec. Again, I'm willing to take on the responsibility of whatever work that entails.