📊 Benchmark Performance Report

group                        base                                   pr
-----                        ----                                   --
pretty-cetz-manual           1.00    723.5±6.22µs        ? ?/sec    1.02   736.4±22.73µs        ? ?/sec
pretty-codly                 1.00  1765.6±40.47µs        ? ?/sec    1.00  1770.3±32.79µs        ? ?/sec
pretty-cpe                   1.00     12.1±0.03ms        ? ?/sec    1.89     22.8±1.57ms        ? ?/sec
pretty-deep-nested-args      1.00     16.5±0.20µs        ? ?/sec    1.01     16.7±0.22µs        ? ?/sec
pretty-fletcher-diagram      1.00    510.4±7.42µs        ? ?/sec    1.00    511.3±7.59µs        ? ?/sec
pretty-fletcher-draw         1.00  1231.9±21.65µs        ? ?/sec    1.01  1242.1±20.52µs        ? ?/sec
pretty-tablex                1.00      3.3±0.01ms        ? ?/sec    1.00      3.3±0.02ms        ? ?/sec
pretty-touying-core          1.01      2.1±0.01ms        ? ?/sec    1.00      2.1±0.02ms        ? ?/sec
pretty-touying-utils         1.00  1190.3±19.14µs        ? ?/sec    1.00  1191.1±18.60µs        ? ?/sec
pretty-undergraduate-math    1.01   847.1±11.43µs        ? ?/sec    1.00   842.8±12.55µs        ? ?/sec

📏 Binary Size Comparison

@@ -1,17 +1,17 @@
 std                       391.6 kB
 clap_builder              342.3 kB
-typstyle_core             215.1 kB
+typstyle_core             214.9 kB
 typst_syntax              141.4 kB
 clap_complete             130.8 kB
 similar                   72.5 kB
 typstyle                  54.7 kB
 walkdir                   19.4 kB
 colored                   9.1 kB
 toml_edit                 9.1 kB
 anyhow                    8.6 kB
-prettyless                7.8 kB
+prettyless                7.7 kB
 hashbrown                 5.5 kB
 path_absolutize           4.2 kB
 clap_lex                  4.0 kB
 anstream                  2.6 kB
 parking_lot               2.6 kB

Generated by GitHub Actions on 2025-07-30 02:35:46 UTC

Without text-wrapping, spaces will not turn to linebreaks, unless they are next to blocky elements (list item, heading, etc).

Does this effectively disables the folloing formatting?

if true [ 1 ] else [ 2 ] 

to

if true [
  1
] else [
  2
]

Without text-wrapping, spaces will not turn to linebreaks, unless they are next to blocky elements (list item, heading, etc).

Does this effectively disables the folloing formatting?

I'd like to leave this decision to users.

Previously, we had two rules, but now they expose problems:

• Tight: when the content is single-line, keep it by preserving boundary spaces. But inner format may change this property, so this rule may lead to divergence.
• Symmetric: when the two boundaries both not nil, they can turn to linebreak when multiline. This works with the tight rule. Without the tight rule, we can discard the symmetry rule.

I'm not sure if I get it correctly. How will we "leave the decision to users"? I didn't see this pr adding a config item for this.(BTW I prefer not adding one).

From code, it looks like in this pr, we remove tight & symm rules and only depends on text wrapping. For users who already depends on tight & symm rules, this is a regression. Would it make sense if we keep tight & symm rules, but also take text wrapping into consideration?

I'm not sure if I get it correctly. How will we "leave the decision to users"? I didn't see this pr adding a config item for this.(BTW I prefer not adding one).

Users can change the boundary space to linebreaks if they find the layout bad, which is also respected by the formatter.

From code, it looks like in this pr, we remove tight & symm rules and only depends on text wrapping. For users who already depends on tight & symm rules, this is a regression. Would it make sense if we keep tight & symm rules, but also take text wrapping into consideration?

The boundary part of this PR makes formatting more conservative, so it will not change existing codebase.
When text wrapping is enabled, we do not preserve any space. Boundary spaces can turn into linebreaks, just as inline spaces.

If the tight rule is causing divergence, would it be possible if we remove tight rule and only keep the symm rule?

If the tight rule is causing divergence, would it be possible if we remove tight rule and only keep the symm rule?

The symm rule targets this case: [ content], [content ]. It becomes implicit as we choose always to preserve spaces.

The key point is whether [ content ] can become

[
  content
]

Considering #296, I want to preserve

[ aaaaa  bbbbbbb cccccccc   ]
[ dddd   eeee    ffffff     ]

where we manually align texts as DSL. In this case, we do not want a wide content block to be broken.

And I forgot one thing. With space collapse enabled, it should keep the original behavior.

Fixes #401

(Adding comment so that it will auto-close the bug.)