Taylor Fausak

Yes, that's correct. I was looking for components that used invalid characters in their names. Looking for component names that are actually invalid package names is a little more complicated....

Similar to https://github.com/tfausak/cabal-gild/issues/63#issuecomment-2030054064, you can work around this problem by defining `ghc-options` multiple times and putting the comments on the field itself: ``` cabal ghc-options: -threaded -Wno-unticked-promoted-constructors -- allow user...

Actually I think this is not a bug. Instead I think that keeping comments as close as possible to their original position is a feature request. Gild tries hard not...

Hmm I'm not sure what you mean about `import`. Do you have an example? Gild should only move comments that are inside field values that it knows how to parse....

Ah right, that is confusing. Thanks for the example! To reproduce it inline: ``` cabal import: foo , bar -- baz , qux ``` Gild will not reformat that. This...

I agree. I think the correct behavior here is to _always_ float comments to the top of field values. That way users don't have to know/care about which fields Gild...

There are two places that will need to change. First is the place where there's no parser for the field: https://github.com/tfausak/cabal-gild/blob/d32c1fb34139f16d714a141e2c067f4335bd9c20/source/library/CabalGild/Unstable/Action/FormatFields.hs#L51 Currently it passes the field through unchanged. It will...

Discovered here: https://github.com/haskell/haskell-language-server/pull/4229#discussion_r1599311876

Rather than my janky `Chunk` type, I think it makes sense to use the proper `Condition ConfVar` for this. https://hackage.haskell.org/package/Cabal-syntax-3.12.0.0/docs/Distribution-Fields-ConfVar.html#v:parseConditionConfVar It will require a bit of a rework to parse...

Unfortunately the `Condition` type doesn't have a `CParen` constructor. That means it can't losslessly round-trip a conditional like this: ``` cabal if !((x || y) && z) ``` The AST...