Conversation
|
|
||
| EncodeSeparate: n.EncodeSeparate, | ||
| EncodeSeparate: n.EncodeSeparate, | ||
| BlankLineBefore: n.BlankLineBefore, |
There was a problem hiding this comment.
Why not put blank lines in the HeaderComment?
There was a problem hiding this comment.
HeadComment is meant to hold comment text. Overloading it with formatting whitespace (e.g. a leading \n for blank-line-only nodes, or \n# actual comment when both are present) mixes two different concerns. Nodes can have a blank line without any comment, and vice versa.
There's also a processing order issue. In the encoder, comments are injected first, then blank lines in a second pass. This makes sure blank lines end up before the comment+attribute group, not between them. Merging both into HeadComment would require a single pass to handle this correctly, making the comment injection logic more complex.
The main reason though is cross-format extensibility. The BlankLineBefore field on CandidateNode is format-agnostic. Right now only HCL uses it, but the same mechanism could be reused by other format decoders (TOML, Properties, potentially YAML) without each one having to encode blank line info into comment strings and then parse it back out. Each decoder just sets a boolean, and each encoder decides how to act on it.
This PR improves HCL roundtrip fidelity by preserving blank lines between blocks and attributes, and correctly re-encoding raw HCL expressions inside flow-style object attributes without wrapping them in quotes.