Conversation
`<group>` chooses between its flat and broken form by asking whether the flat form fits the space left on the current line. That couples two questions a generator often needs to keep apart: how much room is left, and how wide this construct is allowed to be. `max` answers only the second. When it is set, the group's children are measured in their flat form against `max` alone, so the group lays out identically wherever it appears. Style rules that cap a specific construct — argument lists, collection literals, call chains — below the file's print width map onto it directly. When `max` is absent, behaviour is unchanged. The threshold replaces the print width rather than adding to it, and that is what makes the decision column-independent: a group that fits `max` stays flat even when that overruns `printWidth`, leaving an enclosing group to break elsewhere to make room. `shouldBreak`, hard lines and `<breakParent />` still force a break, and `id` still publishes the outcome to `<ifBreak>` / `<indentIfBreak>`. Folded onto `<group>` rather than shipped as a second intrinsic: it is the same axis as `shouldBreak` (a break trigger), callers that don't set it pay nothing, and the API surface stays at one group primitive.
|
All changed packages have been documented.
Show changes
|
commit: |
| * here. | ||
| * | ||
| * Not memoized: the result depends on `hasLineSuffix` as well as on the | ||
| * node, so nesting `max` groups `d` deep re-measures the innermost subtree |
There was a problem hiding this comment.
anything we could do here for the potential performance issue?
we should at least document it on the max property and in the formatting doc
There was a problem hiding this comment.
will have a look if there's a path to optimizing this, else add the suggested docs
There was a problem hiding this comment.
Just to be clear you did want a group with max > printWidth to keep going, not just that this says this group can take up to x amount but it should still fit within the regular lines
There was a problem hiding this comment.
Tnx for the feedback, will look into this: max should not enable a line going over the total printWidth, so at least the text here is wrong/misleading
This branch has not been deployed
2 participants
<group>chooses between its flat and broken form by asking whether the flat form fits the space left on the current line. That couples two questions a generator often needs to keep apart: how much room is left, and how wide this construct is allowed to be.maxanswers only the second. When it is set, the group's children are measured in their flat form againstmaxalone, so the group lays out identically wherever it appears. Style rules that cap a specific construct — argument lists, collection literals, call chains — below the file's print width map onto it directly. Whenmaxis absent, behaviour is unchanged.The threshold replaces the print width rather than adding to it, and that is what makes the decision column-independent: a group that fits
maxstays flat even when that overrunsprintWidth, leaving an enclosing group to break elsewhere to make room.shouldBreak, hard lines and<breakParent />still force a break, andidstill publishes the outcome to<ifBreak>/<indentIfBreak>.Folded onto
<group>rather than shipped as a second intrinsic: it is the same axis asshouldBreak(a break trigger), callers that don't set it pay nothing, and the API surface stays at one group primitive.