feat: make flavor detection more intuitive#362
feat: make flavor detection more intuitive#362QuadnucYard merged 2 commits intotypstyle-rs:masterfrom
Conversation
There was a problem hiding this comment.
Summary of Changes
Hello @QuadnucYard, I'm Gemini Code Assist1! 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_flavoredFunction: A new public function,is_multiline_flavored, has been introduced incrates/typstyle-core/src/pretty/style.rs. This function inspects aSyntaxNode'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,
letbindings, andplacecalls.
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
-
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. ↩
There was a problem hiding this comment.
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.
📊 Benchmark Performance Reportgroup base pr
----- ---- --
pretty-cetz-manual 1.00 743.9±9.54µs ? ?/sec 1.01 750.4±12.65µs ? ?/sec
pretty-codly 1.00 1774.6±20.25µs ? ?/sec 1.00 1773.4±25.53µs ? ?/sec
pretty-cpe 1.00 13.4±0.85ms ? ?/sec 1.00 13.3±1.61ms ? ?/sec
pretty-deep-nested-args 1.00 17.8±0.24µs ? ?/sec 1.00 17.7±0.11µs ? ?/sec
pretty-fletcher-diagram 1.04 539.3±88.69µs ? ?/sec 1.00 516.1±10.80µs ? ?/sec
pretty-fletcher-draw 1.01 1259.2±12.32µs ? ?/sec 1.00 1249.2±36.88µs ? ?/sec
pretty-tablex 1.00 3.3±0.01ms ? ?/sec 1.01 3.3±0.12ms ? ?/sec
pretty-touying-core 1.01 2.1±0.01ms ? ?/sec 1.00 2.1±0.03ms ? ?/sec
pretty-touying-utils 1.01 1202.0±19.65µs ? ?/sec 1.00 1188.1±19.75µs ? ?/sec
pretty-undergraduate-math 1.00 854.4±16.71µs ? ?/sec 1.02 870.6±42.11µs ? ?/sec📏 Binary Size Comparison
📦 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.9 kB
+std 392.0 kB
clap_builder 342.3 kB
-typstyle_core 204.5 kB
+typstyle_core 200.8 kB
typst_syntax 141.4 kB
clap_complete 130.8 kB
similar 72.5 kB
typstyle 54.7 kB
walkdir 19.4 kBGenerated by GitHub Actions on 2025-07-31 08:35:58 UTC |
This comment was marked as outdated.
This comment was marked as outdated.
|
@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 |
This comment was marked as outdated.
This comment was marked as outdated.
1 similar comment
This comment was marked as outdated.
This comment was marked as outdated.
|
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 |
|
pls also resolve the conflict |
Updated |
efb42e0 to
c654ee2
Compare
|
I wonder if we can minimize the behavior change for users. Would it make sense if we take a list as multiline if |
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. |
c654ee2 to
b51150f
Compare
b51150f to
a6ea8e5
Compare
|
pls also update changelog.md 🙏 |
a6ea8e5 to
ba0d4c8
Compare
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:
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.
For another,
the linebreak before
)surprisingly makes it multiline-flavored.Math/Markup flavor detection is not changed.
We need to resolve #356 for them first.