feat: make flavor detection more intuitive

[QuadnucYard]

Previously, we checked if the first space contains any linebreak. But that would be counter-intuitive in view of spaces/linebreaks in children.
With this PR, a list-like syntax is regarded as multiline, if there is a space containing linebreak before its first child expr.

For example:

#arguments(red,stroke: blue,
 yellow)
#arguments(red, stroke: blue,
 green)
#arguments(stroke:
 blue, red)

Previously, the first was multiline flavored, but it differs from the second one only in a space.
Now none of them is multiline flavored.
To make it multiline flavored, you exactly need to insert a linebreak before the first arg.

Math/Markup flavor detection is not changed.
We need to resolve #356 for them first.

[gemini-code-assist]

Summary of Changes

Hello @QuadnucYard, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the pretty printer's ability to detect and handle 'flavors' of code, making the formatting behavior more intuitive. It introduces a new utility function to determine if a syntax node should be considered multiline based on explicit line breaks, which in turn leads to more compact, single-line formatting for many code constructs when no such line breaks are present. This change specifically targets general code formatting, leaving Math and Markup flavor detection unchanged for now.

Highlights

• Improved Flavor Detection: The logic for determining a node's 'multiline flavor' has been refactored into a dedicated, more intuitive function. This change aims to make the formatter's decision-making process for line breaking more aligned with user intent, specifically for non-Math/Markup contexts.
• New is_multiline_flavored Function: A new public function, is_multiline_flavored, has been introduced in crates/typstyle-core/src/pretty/style.rs. This function inspects a SyntaxNode's immediate children for the presence of line breaks within space tokens to determine if the node should be treated as multiline. It prioritizes explicit line breaks over structural complexity for this determination.
• More Compact Formatting: As a direct result of the refined flavor detection, various code constructs that previously formatted across multiple lines will now be formatted on a single line if they do not contain explicit line breaks. This leads to more concise and compact output for elements like function arguments, dictionary literals, let bindings, and place calls.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

The pull request introduces a new is_multiline_flavored function to improve flavor detection. A potential issue in the implementation of this function has been identified and a fix has been suggested to ensure more robust and accurate flavor detection.

[github-actions]

📊 Benchmark Performance Report

group                        base                                   pr
-----                        ----                                   --
pretty-cetz-manual           1.00   719.4±20.01µs        ? ?/sec    1.02   733.6±15.50µs        ? ?/sec
pretty-codly                 1.00  1797.1±24.73µs        ? ?/sec    1.01  1819.3±30.03µs        ? ?/sec
pretty-cpe                   1.01     12.2±0.47ms        ? ?/sec    1.00     12.0±0.05ms        ? ?/sec
pretty-deep-nested-args      1.00     16.3±0.12µs        ? ?/sec    1.05     17.1±0.22µs        ? ?/sec
pretty-fletcher-diagram      1.00   517.3±10.25µs        ? ?/sec    1.01   522.1±10.14µs        ? ?/sec
pretty-fletcher-draw         1.00  1246.4±16.54µs        ? ?/sec    1.02  1266.5±25.44µs        ? ?/sec
pretty-tablex                1.00      3.3±0.01ms        ? ?/sec    1.02      3.4±0.01ms        ? ?/sec
pretty-touying-core          1.00      2.1±0.01ms        ? ?/sec    1.02      2.2±0.01ms        ? ?/sec
pretty-touying-utils         1.00  1201.7±11.19µs        ? ?/sec    1.01  1215.7±12.43µs        ? ?/sec
pretty-undergraduate-math    1.00   830.9±16.66µs        ? ?/sec    1.03   855.1±27.53µs        ? ?/sec

📏 Binary Size Comparison

Metric	Base	PR	Change
File Size	5.7 MB	5.7 MB	📉 -3.7 kB (-0.07%)
Text Section	1.4 MB	1.4 MB	📉 -2.7 kB (-0.19%)

📦 Detailed Crate Size Diff (cargo-bloat)

Note: Numbers above are a result of guesswork. They are not 100% correct and never will be.

@@ -1,8 +1,8 @@
 std                       391.8 kB
 clap_builder              342.3 kB
-typstyle_core             217.5 kB
+typstyle_core             214.8 kB
 typst_syntax              141.4 kB
 clap_complete             130.8 kB
 similar                   72.5 kB
 typstyle                  54.7 kB
 walkdir                   19.4 kB

Generated by GitHub Actions on 2025-07-27 06:24:39 UTC

[Enter-tainer]

@claude explain this PR to me in both Chinese and English. Mainly focus the main changes and potential problems. also tell me why this pr make sense

[Enter-tainer]

Hi, could you please update the pr description and include the latest algo for new flavor detection algorithm? I wonder if we should change docs files as well

[Enter-tainer]

pls also resolve the conflict

[QuadnucYard]

Hi, could you please update the pr description and include the latest algo for new flavor detection algorithm? I wonder if we should change docs files as well

Updated

[Enter-tainer]

I wonder if we can minimize the behavior change for users. Would it make sense if we take a list as multiline if old_method || new_methord is true? Thus users will not see changes after upgrading to latest typstyle

[QuadnucYard]

I wonder if we can minimize the behavior change for users. Would it make sense if we take a list as multiline if old_method || new_methord is true? Thus users will not see changes after upgrading to latest typstyle

It has no effect on well-formatted code, since the two methods give the same results on well-formatted code.

[Enter-tainer]

I wonder if we can minimize the behavior change for users. Would it make sense if we take a list as multiline if old_method || new_methord is true? Thus users will not see changes after upgrading to latest typstyle

It has no effect on well-formatted code, since the two methods give the same results on well-formatted code.

It would be better if we can keep original behavior and adding new feature. BTW we should also change description and examples in docs. This reminds me of the discussion when adding typstyle-wasm based exmaple. When adding new features, we cannot ensure examples still make sense without proper tests.