search

avh4 / elm-format

elm-format formats Elm source code according to a standard set of rules based on the official Elm Style Guide
BSD 3-Clause "New" or "Revised" License
1.31k stars 148 forks source link

Language Server: more than formatting #479

Open dpren opened 6 years ago

dpren commented 6 years ago

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?

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:

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:

avh4 commented 6 years ago

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 commented 6 years ago

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.