haskell / haskell/haskell-language-server

Coherence of command-line formatters versus formatter plugins

Offen
#411 25 Kommentare 12 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
component: formatters Hackathon type: enhancement
Vorherrschende Sprache
Haskell
Sterne
3k
Forks
455
Ø Merge
2 T. 19 Std.
Gemergte PRs (30 T.)
11

Beschreibung

As many people do, I have a gate in my CI that ensures that code passes a formatter before it is merged. That formatter (in this case `stylish-haskell`) is run as an executable.

If I also use HLS, I can format my code with `stylish-haskell` via the formatter plugin. But this will use the version of `stylish-haskell` that HLS was compiled with, not the one that I have (elsewhere) specified for use in CI.

This makes the in-editor formatting useless to me, as I will typically have to reformat with the executable version before my change will pass CI.

I can see two ways to keep things consistent.

1. HLS follows environment

Ultimately I think this would mean that HLS would have to call the executable. I understand that this is undesirable since the current model allows us to use the nicer Haskell interfaces to tools and test them easily.

2. Environment follows HLS

Perhaps we could have some way to format "as-if" using one of the HLS formatting plugins. For example:
- Ship the formatter executables with HLS, so users can call those directly.
- Expose the formatting capabilites through HLS itself as part of the CLI, e.g. `haskell-language-server --format --formatter ormolu Foo.hs`.

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.