Use trailing haddocks for record fields when using leading commas#124
Use trailing haddocks for record fields when using leading commas#124
Conversation
I actually quite prefer to have them indented from the commas, IMO having the commas 'sticking out' like that helps separate the members at glance. When they're lined up with the commas it's kind of one large block; distinguishing dashes from commas is harder than distinguishing space from commas. I suppose the 'most fourmolu' thing to do would be to make this configurable.
|
Ok, sure. Any opinion on naming the flag? I can't think of anything snappier than |
|
Seems fine to me, it's not as if anyone actually types config options out
for a formatter anyway (aside from putting them in their dotfiles once
ever).
Does make me think that my preference of indenting for records but not for
functions is a little inconsistent...
…On Mon, 1 Nov 2021, 5:35 am George Thomas, ***@***.***> wrote:
I suppose the 'most fourmolu' thing to do would be to make this
configurable.
Ok, sure. Any opinion on naming the flag? I can't think of anything
snappier than --indent-trailing-haddocks.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#124 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGRJXA5N4L5IXHIBUN2NZTUJWZCVANCNFSM5HBCUVCA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Good point.
Yeah, it looks pretty weird to me. And doing the analogous thing for functions would require a 3-space indent... But, hey, if you want the option, I'm happy to add it! That's basically our mission statement. |
So as to not be difficult, I'll try this out your way, and if it's really as terrible as my knee-jerk reaction, then I'll implement an option for it myself. |
| { fooX :: Int | ||
| -- ^ X | ||
| , fooY :: Int | ||
| -- ^ Y |
There was a problem hiding this comment.
Personally, I would imagine it lining up better as
{ fooX :: Int
-- ^ X
, fooY :: Int
-- ^ Y(i.e. same indentation + 2 spaces, regardless of indentation size)
More importantly, if a user did
{ fooX :: Int -- ^ X
, fooY :: Int -- ^ Yit seems like fourmolu forces these on the next line. I would expect fourmolu to respect the user's newline here (or lack thereof)
There was a problem hiding this comment.
-
Fair enough, if you and @expipiplus1 both prefer that I'd be happy to support it as an option if someone wants to implement it (once we start clearing the backlog anyway: Merge pull requests #112 (comment)).
-
That really isn't ideal - I'll look in to it.
There was a problem hiding this comment.
- Ah I didn't notice it's what @expipiplus1 said. Yeah, no worries, I'm not terribly bothered by it. I'll open a ticket
- I'll open a ticket for tracking it
There was a problem hiding this comment.
Oh this also causes weird behavior when trying to comment sections of record fields:
Original:
data Foo = Foo
{ -- section 1
a :: Int
, b :: Int
, c :: Int
-- section 2
, d :: Int
, e :: Int
}fourmolu-0.4.0.0:
data Foo = Foo
{ -- section 1
a :: Int
, b :: Int
, c :: Int
- -- section 2
- , d :: Int
+ , -- section 2
+ d :: Int
, e :: Int
}fourmolu-0.5.0.0:
data Foo = Foo
{ -- section 1
a :: Int
, b :: Int
, c :: Int
- -- section 2
- , d :: Int
+ , -- section 2
+ d :: Int
, e :: Int
}Related: #72
This is inspired by (and lifts the core code from) #98.
Differences:
master.sitcccall inOrmolu.Printer.Meat.Type.poCommaStyle, and use trailing haddocks iff it's set toLeading. This removes the "Disallow this in combination with trailing comma style" concern (I'm not sureoptparse-applicativeprovides a nice way to do that). And the old style is so ugly that I really don't see any reason why anyone would prefer it. It's just a relic of adapting Ormolu to leading commas in the simplest way possible.