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

Add fourmolu plugin #161

Closed
wants to merge 31 commits into from
Closed

Add fourmolu plugin #161

wants to merge 31 commits into from

Conversation

georgefst
Copy link
Collaborator

There's an unfortunate amount of code duplication: Fourmolu.hs only has trivial changes from Ormolu.hs, but I don't think there's any sane way to abstract much of that out.

@georgefst
Copy link
Collaborator Author

Actually, this had better not go in until it also supports stack. I believe Matt was going to upload to Stackage once we've fully resolved fourmolu/fourmolu#1.

@fendor
Copy link
Collaborator

fendor commented Jun 14, 2020

Actually, this had better not go in until it also supports stack

shouldnt it just work as an extra-dep?

@georgefst
Copy link
Collaborator Author

shouldnt it just work as an extra-dep?

Oh, probably, yeah. I haven't touched stack in a few years - I've forgotten how that sort of thing works exactly.

@jneira
Copy link
Member

jneira commented Jun 14, 2020

Mmm, maybe only if ormolu would let configure the number of spaces for identantion...
To have to duplicate an entire lib only for change that is... weird

@georgefst
Copy link
Collaborator Author

georgefst commented Jun 14, 2020

To have to duplicate an entire lib only for change that is... weird

Hard to disagree with that. The ormolu team are pretty insistent about the no-config thing though. And there seem to be quite a few of us who think it's a fantastic tool, but find the two spaces issue (and one or two others - in future there will likely be slightly more divergence, but not much) a deal-breaker. It's explained and discussed here.

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.

@fendor
Copy link
Collaborator

fendor commented Jun 14, 2020

To have to duplicate an entire lib only for change that is... weird

At least it adds no additional dependencies 😇

@jneira
Copy link
Member

jneira commented Jun 14, 2020

Well, i would replace ourmolu with fourmolu if the later would let configure the number of spaces.
Maybe i will create another almighty fork that let users choose them 😆

@ndmitchell
Copy link
Collaborator

I think fourmolu has a ticket to add configuration of the number of spaces.

@georgefst
Copy link
Collaborator Author

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 fourmolu in place of ormolu?

Some existing users might be confused if ormolu has gone and they now need to write an explicit configuration file to get its behaviour back. But then it would also be confusing if we had fourmolu using two spaces by default...

@ndmitchell
Copy link
Collaborator

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.

@georgefst
Copy link
Collaborator Author

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.

@jneira
Copy link
Member

jneira commented Jun 18, 2020

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.

@ndmitchell
Copy link
Collaborator

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.

@georgefst
Copy link
Collaborator Author

Well in that case this can go in as-is.

I'll come back and bump the version once we release 0.1 on Hackage, which will have some basic configurability and a minor bugfix, plus upstream changes. Probably within the next week.

@georgefst
Copy link
Collaborator Author

Well, I've got this building locally with Fourmolu 0.1, but we require the latest Aeson, so I've ended up needing:

allow-newer:
  cabal-plan:aeson
  stylish-haskell:aeson
  HsYAML-aeson:aeson
  floskell:aeson

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 cabal-plan (the latest on Hackage already has the relaxed upper bound on Aeson)?

I could go and chase up the maintainers for the other three.

@lukel97
Copy link
Collaborator

lukel97 commented Jul 1, 2020

Looks like cabal-plan should be ok https://hackage.haskell.org/package/cabal-plan for that version of aeson
haskell/stylish-haskell#289

@lukel97
Copy link
Collaborator

lukel97 commented Jul 1, 2020

Also blocking haskell-hvr/HsYAML-aeson#6

@lukel97
Copy link
Collaborator

lukel97 commented Jul 1, 2020

ennocramer/floskell#49

src/Ide/Plugin/Fourmolu.hs Outdated Show resolved Hide resolved
ex = map (("-X" <>) . show') $ S.toList $ D.extensionFlags df
show' x = case show x of
"Cpp" -> "CPP"
s -> s
Copy link
Collaborator Author

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.

Copy link
Collaborator Author

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
Copy link
Collaborator Author

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.

Copy link
Collaborator

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?

Copy link
Collaborator Author

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.

@lukel97
Copy link
Collaborator

lukel97 commented Jul 17, 2020

Ok looks like we might need to go down the hackage trustee route haskell-infra/hackage-trustees#271

georgefst and others added 9 commits July 29, 2020 13:59
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.
Copy link
Collaborator

@lukel97 lukel97 left a 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

Comment on lines 163 to 164
let formatLspConfig provider =
object [ "languageServerHaskell" .= object ["formattingProvider" .= (provider :: Value)] ]
Copy link
Collaborator

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

Suggested change
let formatLspConfig provider =
object [ "languageServerHaskell" .= object ["formattingProvider" .= (provider :: Value)] ]

@lukel97
Copy link
Collaborator

lukel97 commented Jul 31, 2020

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
@georgefst
Copy link
Collaborator Author

I'll try and sort this this evening, if we're happy to leave the two allow-newers in for now.

The final two issues appear to be the result of some fairly careless rebasing on my part...

@georgefst
Copy link
Collaborator Author

It would actually be preferable for #246 and #257 to get merged first.

I can't see that there's anything holding either of them up?

fendor and others added 12 commits July 31, 2020 14:44
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
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 a redundant caching step
@georgefst
Copy link
Collaborator Author

Closing in favour of #264.

@georgefst georgefst closed this Aug 1, 2020
pepeiborra pushed a commit that referenced this pull request Dec 27, 2020
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants