-
-
Notifications
You must be signed in to change notification settings - Fork 367
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
Add fourmolu plugin #161
Add fourmolu plugin #161
Conversation
Actually, this had better not go in until it also supports |
shouldnt it just work as an extra-dep? |
Oh, probably, yeah. I haven't touched |
Mmm, maybe only if ormolu would let configure the number of spaces for identantion... |
Hard to disagree with that. The Having both as dependencies here, and building almost exactly the same code twice, does seem particularly silly. I'd love HLS to have a more dynamic, 'pick-and-mix', plugin architecture (I brieflly discussed this earlier with @alanz), but that doesn't seem likely to happen particularly soon. Edit: the plugin issue is now discussed at #164. |
At least it adds no additional dependencies 😇 |
Well, i would replace ourmolu with fourmolu if the later would let configure the number of spaces. |
I think fourmolu has a ticket to add configuration of the number of spaces. |
Yeah, I'm working on that now. Once that's done, should I open a fresh PR which uses Some existing users might be confused if |
haskell-language-server has always been very free with allowing lots of different Haskell tools to coexist and the user gets to pick. Given Ormulu is popular, it should remain available as a separate option. |
Sorry, I'm confused - are you now saying we should have both? I thought the consensus here was shifting the other way e.g. from @jneira's comments. And the question of Fourmolu's configurability isn't as relevant if both are in HLS. I personally don't mind either way. |
Well, i am still thinking include two formatters libs that only differ in one literal is really weird from a pure technical poitn of view. And more if one of them let you behave like the other one. What will happen if one update its dependencies before the other one and both are incompatibles? We will have the responsability of make both compile with the same configuration. That said, i dont have a good solution to @georgefst and @ndmitchell points so i will not be against to link both. |
I think having two formatters that differ by one literal is a bit mad. But the Haskell community does, and that's separate from HLS. Once you have those two formatters, I don't think HLS should be the ones to pick between them - in all other aspects we're delightfully non-picky - Cabal/Stack/Nix/Obelisk/Bash or whatever. I don't see any reason to start here. Note that all the concerns of compatible libraries etc apply equally to other libraries - e.g. we can't statically link two things that require different versions of haskell-src-exts etc. I suspect an eventual solution will be to demand that everything we use as a plugin is in Stackage nightly, and then that guarantees there is a solution that works for all. |
Well in that case this can go in as-is. I'll come back and bump the version once we release |
Well, I've got this building locally with Fourmolu 0.1, but we require the latest Aeson, so I've ended up needing:
The changes in 1.5 seem pretty unlikely to have broken anything, and there's a bugfix I'd rather not have to work around, hence the restrictive lower bound. I assume there's a good reason we're using a fork of I could go and chase up the maintainers for the other three. |
Looks like cabal-plan should be ok https://hackage.haskell.org/package/cabal-plan for that version of aeson |
Also blocking haskell-hvr/HsYAML-aeson#6 |
src/Ide/Plugin/Fourmolu.hs
Outdated
ex = map (("-X" <>) . show') $ S.toList $ D.extensionFlags df | ||
show' x = case show x of | ||
"Cpp" -> "CPP" | ||
s -> s |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This'll do for now. Really, we shouldn't have to rely on show
here anyway...
It actually looks like it wouldn't take much of a refactoring to allow passing the DynFlags
directly. I'll see if I can get this fixed upstream in Ormolu.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It actually looks like it wouldn't take much of a refactoring to allow passing the DynFlags directly.
Turns out to be slightly tricky because of the ghc
/ghc-lib
type mismatch. I'll be curious to see how @jneira solves this issue for HLint.
allow-newer: | ||
floskell:aeson | ||
HsYAML-aeson:aeson | ||
stylish-haskell:aeson |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably want to remove these before merging.
I've got an eye on the relevant PRs - thanks @bubba for opening them where necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the remaining packages blocked by aeson-1.5?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Floskell got the bump, but there hasn't been a Hackage release with it.
We're still waiting on Stylish.
Ok looks like we might need to go down the hackage trustee route haskell-infra/hackage-trustees#271 |
Seeing as, since haskell#209, the README suggests globally enabling `-haddock`, it's rather unfortunate for that not to work with HLS' own installation script...
Fix haddock parse error in install.hs
The original lineno extracted from the Addition DiffOperation needs to be increased by 1.
We were taking max of l and sl but the position of an insertion in the newer document is irrelevant since the edits will be applied from bottom to top.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you mean to update the ghcide submodule? Other than that I think we can live with the allow-newers for now, this PR looks great and it's been collecting dust here for a while now
test/functional/Format.hs
Outdated
let formatLspConfig provider = | ||
object [ "languageServerHaskell" .= object ["formattingProvider" .= (provider :: Value)] ] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Already defined on lines 172-173
let formatLspConfig provider = | |
object [ "languageServerHaskell" .= object ["formattingProvider" .= (provider :: Value)] ] |
We should also probably incorporate the fix from #246 into this as well. Either with this PR or in a separate one |
Hoogle nor happy nor cabal-helper shouldn't be needed anymore
I'll try and sort this this evening, if we're happy to leave the two The final two issues appear to be the result of some fairly careless rebasing on my part... |
Ormolu flags
Use @? and @?= instead, since they give much easier to read error messages. The `shouldX` functions all just end up dumping the Show instance of a HSpecFailure or what have you which is really hard to read. It also doesn't look like hspec-expectations is that actively maintained anymore
…-steps Remove redundant CircleCI steps
Fixes flakey CI builds. Turns out it was trying to run every single test in parallel at once, which is why when haskell#247 added two extra tests it was just enough to push it over the limit and cause things to fail
Slow down Tasty by limiting it to -j1
Remove hspec-expectations
Remove a redundant caching step
Closing in favour of #264. |
Experience shows that people sometimes mistakenly start `ghcide` on the command line with the `--lsp` option (which is intended to be used only in server/client communication scenarios) and then wonder why nothing is working.. So let's issue a warning message whenever `--lsp` is used.
There's an unfortunate amount of code duplication:
Fourmolu.hs
only has trivial changes fromOrmolu.hs
, but I don't think there's any sane way to abstract much of that out.