Require parentheses in all function-like sub/superscripts by mkorje · Pull Request #6442 · typst/typst

mkorje · 2025-06-13T07:46:50Z

Reverts #985, removing the "smart" treatment of function like stuff. This solution ensures things are consistent across symbols, function calls, literal characters, etc. (cf. #5605). AFAIK This has been the consensus reached as the best and final option. Whilst there could in the future be runtime math parsing - which would likely mean another change here - that would be a fairly large throughout math in any event and enable the "perfect" solution. So I think it would be okay to change again for that.

The changes in summary:

#set page(width: auto)
$a_1(x), a^10(x), a_f(x), a^zeta(x), a_"text"(x),
 a_∂(x), a^cos(x), a_abs(x), a^root(2, x), a_subset.eq(x) \
 a_(1(x)), a^(10(x)), a_(f(x)), a^(zeta(x)), a_("text"(x)),
 a_(∂(x)), a^(cos(x)), a_(abs(x)), a^(root(2, x)), a_(subset.eq(x))$

Old	New

laurmaedje · 2025-06-13T08:16:43Z

I agree that this change is necessary and that we've waited far too long for the perfect solution.

That said, I think we should help out people a bit with migrating back to this behaviour. Since the current behaviour is rather rarely the desirable one, I imagine that most people will only have superfluous spaces after this change instead of breakage. However, people that are using Typst functions in attachments will have silent breakage. I think we should thus issue a warning when a Typst function (like abs) is used as an attachment.

Any other ideas for warnings we could issue?

A general migration assistant would also be really useful for changes like this, but that's another story.

Enivex · 2025-06-13T13:22:15Z

Fractions have a similar problem as well

#4717 is relevant

laurmaedje · 2025-06-13T13:27:34Z

I'm not sure I agree that it's a problem for fractions. I would naturally expect function calls to bind more tightly than fractions, e.g. in f(x)/g(x).

Enivex · 2025-06-13T13:44:47Z

I'm not sure I agree that it's a problem for fractions. I would naturally expect function calls to bind more tightly than fractions, e.g. in f(x)/g(x).

The thing is that you don't know if something is actually a function or not, which is the same problem as for fractions.

1/2(a+b) is interpreted as (1/2)*(a+b), which is correct when strictly following standard precedence rules. However 1/c(a+b) is interpreted as 1/(c(a+b)).

mkorje · 2025-06-25T06:06:14Z

That said, I think we should help out people a bit with migrating back to this behaviour. Since the current behaviour is rather rarely the desirable one, I imagine that most people will only have superfluous spaces after this change instead of breakage. However, people that are using Typst functions in attachments will have silent breakage. I think we should thus issue a warning when a Typst function (like abs) is used as an attachment.

I've got a warning working, but it also includes user's functions. But for some reason the span seems quite off for user's functions:

--- playground ---
$a^abs(x) a^(abs(x)) a^abs a^(abs)$
$a_abs(x) a_(abs(x)) a_abs a_(abs)$
$a^std.math.abs(x) a^(std.math.abs(x)) a^std.math.abs a^(std.math.abs)$
$a_std.math.abs(x) a_(std.math.abs(x)) a_std.math.abs a_(std.math.abs)$

#let aa = $a$
#let a = $a$
$a^#a a^aa$

#let myfunc(x) = if x == none {} else {}
#let f(x) = if x == none {} else {}
$a^myfunc(x) a^(myfunc(x)) a^myfunc a^(myfunc)$
$a^#f($x$) a^#f$

Warnings

warning: function literal used as superscript
  ┌─ tests/suite/playground.typ:1:3
  │
1 │ $a^abs(x) a^(abs(x)) a^abs a^(abs)$
  │    ^^^
  │
  = hint: wrap the entire function call in parentheses

warning: function literal used as superscript
  ┌─ tests/suite/playground.typ:1:23
  │
1 │ $a^abs(x) a^(abs(x)) a^abs a^(abs)$
  │                        ^^^
  │
  = hint: wrap the entire function call in parentheses

warning: function literal used as subscript
  ┌─ tests/suite/playground.typ:2:3
  │
2 │ $a_abs(x) a_(abs(x)) a_abs a_(abs)$
  │    ^^^
  │
  = hint: wrap the entire function call in parentheses

warning: function literal used as subscript
  ┌─ tests/suite/playground.typ:2:23
  │
2 │ $a_abs(x) a_(abs(x)) a_abs a_(abs)$
  │                        ^^^
  │
  = hint: wrap the entire function call in parentheses

warning: function literal used as superscript
  ┌─ tests/suite/playground.typ:3:3
  │
3 │ $a^std.math.abs(x) a^(std.math.abs(x)) a^std.math.abs a^(std.math.abs)$
  │    ^^^^^^^^^^^^
  │
  = hint: wrap the entire function call in parentheses

warning: function literal used as superscript
  ┌─ tests/suite/playground.typ:3:41
  │
3 │ $a^std.math.abs(x) a^(std.math.abs(x)) a^std.math.abs a^(std.math.abs)$
  │                                          ^^^^^^^^^^^^
  │
  = hint: wrap the entire function call in parentheses

warning: function literal used as subscript
  ┌─ tests/suite/playground.typ:4:3
  │
4 │ $a_std.math.abs(x) a_(std.math.abs(x)) a_std.math.abs a_(std.math.abs)$
  │    ^^^^^^^^^^^^
  │
  = hint: wrap the entire function call in parentheses

warning: function literal used as subscript
  ┌─ tests/suite/playground.typ:4:41
  │
4 │ $a_std.math.abs(x) a_(std.math.abs(x)) a_std.math.abs a_(std.math.abs)$
  │                                          ^^^^^^^^^^^^
  │
  = hint: wrap the entire function call in parentheses

warning: function literal used as superscript
   ┌─ tests/suite/playground.typ:10:11
   │
10 │ #let myfunc(x) = if x == none {} else {}
   │            ^^^
   │
   = hint: wrap the entire function call in parentheses

warning: function literal used as superscript
   ┌─ tests/suite/playground.typ:11:6
   │
11 │ #let f(x) = if x == none {} else {}
   │       ^^^
   │
   = hint: wrap the entire function call in parentheses

mkorje · 2025-06-25T06:30:18Z

Fractions have a similar problem as well

Fractions aren't quite as simple to "fix". For the denominator its easy, but for the numerator we have the same problem with fixing the #896 equivalent for fractions: we've already parsed it and can't go back.

laurmaedje · 2025-06-25T10:45:47Z

I've got a warning working, but it also includes user's functions.

I think including user function is good, isn't it?

But for some reason the span seems quite off for user's functions:

I suggest using the span of the attachment expr instead of the span of the function. That should fix it.

mkorje · 2025-06-25T11:25:15Z

I think including user function is good, isn't it?

Yes I think so, but I wasn't sure if you might think that's too broad.

I suggest using the span of the attachment expr instead of the span of the function. That should fix it.

Oh that's quite obvious. I've done that now.

laurmaedje · 2025-07-07T13:44:42Z

Before merging this, I wanted to go through the topic one more time. I've done this over the past weeks and collected my thoughts on the topic in a blog post: https://laurmaedje.github.io/posts/math-mode-problem/

The TLDR is that my opinion has shifted back and forth over the past two weeks, but that I'm now quite firmly of the opinion that the PR should be merged and that it is not just a temporary, but the final solution (and not something like runtime parsing).

However, I want to wait one more week for people to voice opinions, should they wish to.

YDX-2147483647 · 2025-07-08T06:37:29Z

Hi! I didn't know a discussion is going on until I saw the blog. I appreciate your effort, but I want to express my objection: I vote for Option A Do nothing over Option B Revert to Typst 0.3 behavior.

If I understand correctly, this PR aims to improve syntax consistency, but at the cost of turning something that can be resolved by inserting a space, into something requiring additional parentheses.

Result: $f_n (x)$ and $e^{f(x)}$
The shortest math markup:
- Before: f_n (x) and e^f(x)
- After: f_n(x) and e^(f(x)).

A predictable, concise, but inconsistent convention is acceptable

However, math is primarily about writing — not programming. If all choices of convention is equally predictable, I think it’s reasonable to choose the one that is more concise but less consistent.

f_n(x) ≠ f_n (x) is just like the divergence between code & markup mode, and x-y ≠ x - y.
It seems odd at first glance, but becomes handy once you know it. We could add a teaching example to the tutorial.

Some analogies from other domains:

In programming, we strictly distinguish between functions and their evaluated results, even type(f + g) ≠ type(f(x) + g(x)).
But in math, we often mix them without confusion — $f + g$ and $f(x) + g(x)$ usually mean the same thing.
In Python, id(some_integer) doesn't behave consistently due to small integer caching, but it's acceptable:
Example python code
```
 >>> x = 5
 >>> id(x) == id(5)
 True
 >>> x = 12345543
 >>> id(x) == id(12345543)
 False
```

More parentheses, harder editing

Adding more parentheses also makes editing formulas much more cumbersome.
While the change makes it clearer about how elements are grouped, it can make it less clear about how parentheses are paired.

Let's say changing the first formula below into the second, then into the third.

(with physica imported)

Before:

$ evaluated(e^sin(x))_abs(u+v) $
$ evaluated(e^sin((n pi) / (N+1)))_abs(u+v) $
$ evaluated(e^sin((n pi) / (N+1) + theta))_abs(u+v) $

After:

$ evaluated(e^(sin(x)))_(abs(u+v)) $
$ evaluated(e^(sin((n pi) / (N+1))))_(abs(u+v)) $
$ evaluated(e^(sin((n pi) / (N+1) + theta)))_(abs(u+v)) $

Even though there's only one pair of () in the formula, the old syntax uses 3 → 5 → 5 pairs, making it hard enough to find where to insert + theta. However the new syntax increases that to 5 → 7 → 7 pairs, which is crazy.

LaTeX (only for reference):

% \usepackage{physics}
\begin{align}
  \eval{e^{\sin(x)}}_\abs{u + v} \\
  \eval{e^{\sin(\frac{n\pi}{N+1})}}_\abs{u + v} \\
  \eval{e^{\sin(\frac{n\pi}{N+1} + \theta)}}_\abs{u + v} \\
\end{align}

In VS Code, nested parentheses are colorized by level, which helps a bit. But in typst.app, all parentheses are black.

(As Enivex has mentioned, #4717 also describes the trouble. That issue proposes a solution, which is another story and I reserve my opinion.)

Maybe collect more voices?

In my opinion, Discord & PR can be biased. If you think there's a problem and want changes, then you are more likely to search for and participate in the discussion. Meanwhile, if I don't see it an issue or oppose the change, then I might not even be aware that a discussion is happening.

Could we consider reaching out to a broader audience?
Maybe, posting it officially on the Typst Forum, or wait this until typst 0.15 and ask for feedback in typst 0.14 release notes, or anything other methods?

laurmaedje · 2025-07-08T08:38:08Z

If I understand correctly, this PR aims to improve syntax consistency [...]

The main aim is not to improve consistency. The current system and option B are equally consistent¹: Right now, function calls have higher precedence than attachments. With option B, attachments have higher precedence.

The aim instead is to resolve an unintuitive behavior that many people stumble into, which is that f_n(x) puts the parentheses into the subscript. From all I could observe, this is simply not what most people expect.

[...] but at the cost of turning something that can be resolved by inserting a space, into something requiring additional parentheses.

I think the crucial part is that with option B, the ambiguity is always resolved into something that reads naturally: It's easily understandable and clear what e^(abs(x)) is doing.

Meanwhile, with option A, the ambiguity is resolved into something that reads unnaturally and feels strange for many people: f_i (x) just feels wrong because you also wouldn't ever write f (x). The space here reads like an implied multiplication rather than a function application.

However, math is primarily about writing — not programming. If all choices of convention is equally predictable, I think it’s reasonable to choose the one that is more concise but less consistent.

I would say that typically consistency is actually more important than slightly shorter notation, as it makes things easier to learn and read.

In VS Code, nested parentheses are colorized by level, which helps a bit. But in typst.app, all parentheses are black.

I honestly think the current feature set of typst.app shouldn't inform the language design. I think distinguishing at a highlighting level which brackets are rendered and which aren't would definitely be a great feature, and colorization maybe as an optional add-on (though I personally am not a fan).

Meanwhile, if I don't see it an issue or oppose the change, then I might not even be > aware that a discussion is happening.

Could we consider reaching out to a broader audience?

This is a fair point. I'm not sure I want to wait for 0.15 and it's not like 0.14 will release next week. But posting on the Forum definitely can't hurt.

There is a slight inconsistency right now because f_1(x) renders differently than f_a(x). Because 1(x) is not considered a function call. ↩

laurmaedje · 2025-07-08T08:45:30Z

I created a Forum post asking for opinions.

OverflowCat · 2025-07-09T01:44:43Z

Here is just my rough idea: I think the core of the issue here is that whitespace in Typst's math mode has semantic meaning, but that meaning isn't currently clear. If we educate users with this principle, it could be easily understood and provide a unified logic.

"We already have the concept of a space being needed for implied multiplication"

This isn't correct; it's just the visual arrangement of symbols, e.g. A inter B.

"Of course, you could require the opposite (i.e. 1/(x(a+b))), but I’m not convinced it’s better."

Actually, I prefer this way. One of the big advantages of Typst's math mode over TeX, in my opinion, is the reduction in parentheses. If a simple space can resolve a nesting issue, that should be the preferred solution. Take 1/2(a+b): interpreting 2(a+b) as part of the denominator would make input more convenient, especially because if you do not want this, you can just add a space before the parenthesis. In more extreme cases, like f(x)/a(b+c)d(e), all continuously written parentheses should be treated as a high-precedence unit. By this design we can remove many parentheses for fractions.

Since we determine that math mode primarily handles display, f (x) is then perfectly acceptable. We also shouldn't differentiate between any symbols; for example, 1(x) is used as Heaviside step function in signal processing.

Other thoughts:

If we want to make math mode even more semantic, we can use the type system (still up in the air) to let user define what is a function, but that will be way too complex.

laurmaedje · 2025-07-09T12:54:54Z

"We already have the concept of a space being needed for implied multiplication"

This isn't correct; it's just the visual arrangement of symbols, e.g. A inter B.

I didn't mean that every space means implied multiplication, but that a space can be necessary to write an implied multiplication (e.g. in a b).

If a simple space can resolve a nesting issue, that should be the preferred solution.

I'm not sure what exactly you mean with "[s]ince we determine that math mode primarily handles display", but as mentioned in my previous comment, I personally am of the opinion that having the source read intuitively and produce intuitive output is more important than a minor save in length of the equation.

bilgincoskun · 2025-07-10T10:04:04Z

As someone who follows and occasionally tests Typst, I vote for option A. While this behavior initially seemed strange, I quickly got used to it. Inserting spaces between subscripts felt very quick and natural. To me, B is like Latex parentheses and is more verbose than option A.

surbliss · 2025-07-20T11:48:00Z

I made a post on the Forum-discussion, but I will cross-post it here for visibility:

I know I’m a bit late, but I think that an Option F is missing from the suggested solutions: Always greedily match subscripts as far right as possible. That is, f_i(x), f_1(2+2) or g_3(y) would put everything to the right of _ into the subscript. This eliminates all ambiguity, and lets the user determine this with spaces.

This behavior mirrors what new users encounter with implicit multiplication: Writing ab + x produces an error, as ab is parsed as a function. Thus, they have to write a b + x. In exchange, they get functions without leading delimiters (# or \), leading to much cleaner syntax.

The same can be applied for subscripts. In long expressions, reducing parentheses makes code more readable. Letting users control subscripts with x_2(i+1) or f_2 (i+1) achieves this.

Cons:

Requires more spaces in the simple cases such as f_1 (x)
For simple subscripts, this contradicts the expected behavior from LaTeX, unlike the proposed solution.
Is a breaking change, (with wide-spread effect)

Pros:

Achieves the same unambiguous parsing as the proposed solution
Allows using spaces as a typographic tool, leading to more readable syntax-code than wide parentheses.

I hope this option can be considered -- I think a minimal syntax is a key strength of Typst, and is a goal that should be pursued.

NicoWeio · 2025-07-20T12:11:27Z

To those arguing for Option A:
Doing nothing would also mean that the IMO unintuitive, thus undesirable, difference between f_1(x) and f_g(x) (rendered as f_1 (x) and f_(g(x))), as discussed in #2086, would stay, or otherwise still require a breaking change, albeit of slightly smaller scope.

matteosantama · 2025-07-26T02:05:01Z

Having just started my first project in typst, I can say I really appreciate its conciseness. FWIW I am in favor of Option F, proposed by @surbliss. Typing a space is much easier than adding a pair of left-right brackets.

laurmaedje · 2025-07-28T08:50:05Z

Isn't Option F basically the status quo with a small extension to also handling numbers like identifiers? All the downsides of Option A apply just the same and my points on this would essentially be #6442 (comment).

bilgincoskun · 2025-07-28T09:38:24Z

In my opinion, F (and A) are more convenient and read more naturally, especially when dealing with nested parentheses. I think the real problem with user expectations isn't the lack of parentheses, but rather the inconsistency. If the distinction between numbers and identifiers were eliminated, and the subscript part was greedily matched, users would adapt as soon as they encountered it.

laurmaedje · 2025-07-28T09:41:52Z

@bilgincoskun Interestingly though, right above you said "While this behavior initially seemed strange". Isn't that sort of in conflict with it "read[ing] more naturally"?

bilgincoskun · 2025-07-28T10:01:39Z

@laurmaedje Not exactly. In my first comment, I meant that I tried writing this way because I was familiar with Latex, and I encountered unexpected behavior compared to it and I think it is fair to assume that most Typst users are familiar with Latex and subscript problem stems from the habits transferred from Latex.

However, after that first encounter, I started writing as f_x (x), and it became easier for me to read and write. I think the more concise writing outweighs the the initial confusion. I hope this clarifies my thoughts.

laurmaedje · 2025-07-28T10:23:58Z

I see. Personally, I still think that f_x(x) is more natural than f_x (x) as f(x) is also more natural than f (x), but I can still how some people might prefer brevity over some perceived naturalness.

I don't think it's possible to make everyone happy here regardless of what we do.

surbliss · 2025-07-28T10:32:52Z

Isn't Option F basically the status quo with a small extension to also handling numbers like identifiers? All the downsides of Option A apply just the same and my points on this would essentially be #6442 (comment).

The primary point of option F is to utilize spaces for typography, rather than trying to infer semantics. Extending the current behavior to numbers does, in my opinion, increase readability. It enforces the rule "Spaces indicate what goes into the subscript". Enforcing this behavior consistently helps users learn to read the spaces in f_x (x) and f_2 (x) as "This space is where the subscript ends".

I see. Personally, I still think that f_x(x) is more natural than f_x (x) as f(x) is also more natural than f (x), but I can still how some people might prefer brevity over some perceived naturalness.

I don't think it's possible to make everyone happy here regardless of what we do.

I think the same could be said for writing a b+c rather than ab+c, as you can in Latex. But there is obviously a very good reason to require spaces for implicit multiplication. Avoiding backslashes in math-expressions is to me one of the main selling points of Typst over Latex.

laurmaedje · 2025-08-01T08:24:15Z

Some time has passed since I've asked for feedback and there were quite a few responses on this PR and in the Forum. There were some voices for most of the Options (stay as-is, revert to 0.3, runtime-dependant parsing), including for an option not included in my blog post: Basically Option A on steroids, where we expand the current behaviour to numbers (Option F).

If you're interested in the individual arguments, I invite you to reread the discussion as I can't fully reproduce everything here. But as a quick summary: The main argument in favor of Option B was predictability while the main argument in favor of Option A and F was terseness, primarily avoidance of additional parentheses, which can make equations harder to read.

There is no way to make everyone happy here, so it's going to be a difficult decision either way. Personally, I believe that predictable, consistent, and intuitive syntax is more important than a bit of extra tersity (this is also in line with Typst's generally design philosophy). While I wouldn't say there is clear consensus, the majority of upvotes on both GitHub and in the Forum seem to share this sentiment. For this reason, I have decided to move forward with Option B.

Thanks to everybody who left feedback, in particular also those that argued for other options. Also thanks to @mkorje of course, for the PR!

Trebor-Huang · 2025-09-03T22:53:46Z

A general migration assistant would also be really useful for changes like this, but that's another story.

Now that the decision has been made, maybe we can talk more about this? I would very strongly prefer if we have a "proper" migration tool, using the full parser instead of (say) adhoc regex replacements based on heuristics, guaranteeing correctness.

laurmaedje · 2025-09-04T09:29:42Z

We can start talking about this for the future, but for this particular change and 0.14, we don't have the capacity to ship that in time.

… upstream (#1) * Numbering implementation refactor (typst#6122) * Pin colspan and rowspan for blank cells (typst#6401) * Clean up some parser comments (typst#6398) * Autocomplete fixes for math mode (typst#6415) * Update docs for gradient.repeat (typst#6385) * Document how to escape lr delimiter auto-scaling (typst#6410) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Improve number lexing (typst#5969) * Report errors in external files (typst#6308) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Table multiple headers and subheaders (typst#6168) * Use the shaper in math (typst#6336) * Standardize trailing slashes in docs route paths (typst#6420) * Make a more descriptive definition of `module` (typst#6380) * Specify which CSL style is not suitable for bibliographies (typst#6306) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Adjust source file API surface (typst#6423) * Do not force `math.mid` elements to have the Large math class (typst#5980) * List both YAML file extensions in bibliography docs (typst#6426) * Fix panic when test source is not found in world (typst#6428) * Use `codex::ModifierSet` (typst#6159) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Render `#super` as `<sup>`, `#sub` as `<sub>` in HTML (typst#6422) * Warning when watching stdin (typst#6381) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Fix untidy Cargo.lock * Warn when using variable fonts (typst#6425) * Check that all translation files are added to TRANSLATIONS and ends with newline (typst#6424) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Unify `EvalMode` and `LexMode` into `SyntaxMode` (typst#6432) * Consume `data` argument in `pdf.embed()` (typst#6435) * Better error message for compile time string interning failure (typst#6439) * Ensure that label repr is syntactically valid (typst#6456) * Hint for label in both document and bibliography (typst#6457) * Prefer `.yaml` over `.yml` in the docs (typst#6436) * Fix align link in layout documentation (typst#6451) * Fix param autocompletion false positive (typst#6475) * Encode empty attributes with shorthand syntax * Add `Duration::decompose` * Generic casting for `Axes<T>` * More type-safe color conversions * Add `typst_utils::display` * Support for generating native functions at runtime * Typed HTML API (typst#6476) * Consistent codepoint formatting in HTML and PDF error messages * Test runner support for HTML export errors * Turn non-empty void element into export error * Handle pre elements that start with a newline * Extract `write_children` function * Properly handle raw text elements * Fix stroke cap of shapes with partial stroke (typst#5688) * Adding Croatian translations entries (typst#6413) * Rewrite `outline.indent` example (typst#6383) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Use ICU data to check if accent is bottom (typst#6393) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Add docs for `std` module (typst#6407) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Improve equation reference example (typst#6481) * Add page reference customization example (typst#6480) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Bump `krilla` to current Git version (typst#6488) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Check that git tree is clean after build (typst#6495) * Also fix encoding of `<textarea>` (typst#6497) * Minor fixes to doc comments (typst#6500) * Fix typos in page-setup.md (typst#6499) * Support `in` operator on strings and modules (typst#6498) * Consistent sizing for `html.frame` (typst#6505) * Allow deprecating symbol variants (typst#6441) * Disallow empty labels and references (typst#5776) (typst#6332) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Fix nested HTML frames (typst#6509) * Basic support for text decoration functions in HTML (typst#6510) * Improve sentence in guide for LaTeX users (typst#6511) * Sort line items by logical order when constructing frame (typst#5887) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Fix panic when sampling across two coincident gradient stops (typst#6166) * Bump `typst-dev-assets` (typst#6514) * Acknowledgements (typst#6528) * Support HTML tests in test-helper extension (typst#6504) * Fix typo in Advanced Styling docs tutorial (typst#6517) * Fix typo in PDF standard CLI help (typst#6518) * Fix typo in PDF standard CLI help part 2 (typst#6531) * Fix minor typo in `array.product` docs (typst#6532) * Fix typos in calc module docs (typst#6535) * Use "subs" and "sups" font features for typographic scripts (typst#5777) * Use punctuation math class for Arabic comma (typst#6537) * Remove duplicate language computation (typst#6557) * Fix typo in PackageStorage (typst#6556) * Fix nightly warnings (typst#6558) * Fix minor typo in function docs (typst#6542) * Refer to json function instead of deprecated json.decode in groups docs (typst#6552) * Rewrite foundations of native elements (typst#6547) * Target-specific native show rules (typst#6569) * Construct library via extension trait instead of default & inherent impl (typst#6576) * Move `html` module to `typst-html` crate (typst#6577) * Fix typo of Typst domain in quote docs (typst#6573) * Anti-alias clip paths (typst#6570) * Use "displayed" instead of "repeated" to avoid ambiguity in numbering docs (typst#6565) * Ignore spans when checking for RawElem equality (typst#6560) * Add `default` argument for `str.first` and `str.last` (typst#6554) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Add completions subcommand (typst#6568) * Update Swedish translations based on defaults used for LaTeX and cleveref (typst#6519) * Move math styling to codex and add `math.scr` (typst#6309) * More consistent `Packed<T>` to `Content` conversion methods (typst#6579) * Support images in HTML export (typst#6578) * Fix tooltip for figure reference (typst#6580) * Complete movement of HTML export code to `typst-html` (typst#6584) * Handle `lower` and `upper` in HTML export (typst#6585) * Deduplicate labels for code completion (typst#6516) * Fix regression in reference autocomplete (typst#6586) * Use "whitespace" instead of "space" to denote block-level equation in docs (typst#6591) * Fix minor typo in text docs (typst#6589) * Rephrase docs for truncation of float/decimal to integer (typst#6543) * HTML frame improvements (typst#6605) * Change `enum.item.number` to `Smart` instead of `Option` (typst#6609) * Support setting fonts repeatedly with different `covers` (typst#6604) * Support intra-doc links in HTML (typst#6602) * Partially automate span assignment in native show rule (typst#6613) * Bump `zip` dependency (typst#6615) * Restore timing scopes for native show rules (typst#6616) * Slightly improve selector docs (typst#6544) * Add show rule for smallcaps in HTML (typst#6600) * Mention Tinymist in README.md (typst#6601) * Fix documentation oneliners (typst#6608) * Add rust-analyzer to flake devShell (typst#6618) * Add Lithuanian translations (typst#6587) * Bump CI Rust to 1.88 * Bump MSRV to 1.88 * Migrate to 2024 edition * Fix 2024 clippy warnings * Yeet `if_chain` macro * Reformat with 2024 edition * Add support for PDF embedding (typst#6623) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Add `pdf` extension to image autocompletions (typst#6643) * Fix bounding box computation for lines in curves (typst#6647) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Lint for iterations over hash types (typst#6652) * Create constructor methods for manifest types (typst#6625) * Remove unnecessary `comemo` dependency in `typst-syntax` (typst#6668) * Remove duplicate center alignment style for equations (typst#6667) * Fix incorrect `vline.x` docs (typst#6657) * Miscellaneous minor docs improvements (typst#6651) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Allow explicit autocomplete immediately after comma and colon (typst#6550) * Improve Guide for LaTeX users, Query Function, and replace invisible emojis (typst#6620) Co-authored-by: PgBiel <9021226+PgBiel@users.noreply.github.com> Co-authored-by: Laurenz <laurmaedje@gmail.com> * Hint that deprecated items will be removed in `0.15.0` (typst#6617) * Specify the standard smart quotes for `Arabic` (typst#6626) * Use `rustc-hash` for hash maps and sets (typst#6678) * Faster constraint checking in comemo (bumps comemo & krilla) (typst#6683) * Add `--target` argument for `typst query` (typst#6405) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Require parentheses in all function-like sub/superscripts (typst#6442) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Fix several wrong anchors in `$` docs link resolution (typst#6684) * Add `cargo testit` alias for running integration tests (typst#6682) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Update guides welcome text to refer to list instead of specific guides (typst#6685) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Prevent broken glyph assemblies when font data is incorrect (typst#6688) * Allow custom element names in HTML tag syntax (typst#6676) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Add interface to disable timer (typst#6695) Co-authored-by: Derived Cat <hooyuser@outlook.com> * Add support for drawing COLR glyphs in SVG export (typst#6693) * Apply aspect ratio correction for linear gradients in PDF export (typst#6689) * Wrap raw blocks in `<code>` tag additionally to `<pre>` tag (typst#6701) * Support for raw syntax highlighting in HTML export (typst#6691) * Ensure that whitespace is not collapsed in inline raw blocks (typst#6703) * Show aliases of citation styles in docs and completions (typst#6696) * Correct CeTZ spelling (typst#6706) * Add `title` element (typst#5618) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Make HTML data structures cheaper to clone (typst#6708) * Move `par`, `box`, and `block` to show rules in HTML export (typst#6709) * Support smartquotes in HTML export (typst#6710) Co-authored-by: Malo <57839069+MDLC01@users.noreply.github.com> * Avoid dangling reference output for HTML tests (typst#6711) * Support multiple fonts in math (typst#6365) * Add link to position field of grid.hline and grid.vline docs (typst#6670) * Rename `pdf.embed` to `pdf.attach` (typst#6705) * Include numbering in PDF bookmark (typst#6622) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Document escaping semicolon, valid identifiers, and `state` tips (typst#6674) Co-authored-by: Andrew Voynov <37143421+Andrew15-5@users.noreply.github.com> Co-authored-by: Yaksher <yaksher.git@gmail.com> Co-authored-by: Laurenz <laurmaedje@gmail.com> * Ensure table headers trigger rowbreak (typst#6687) * Fix phrasing of iff (if and only if) in docs (typst#6713) * Remove redundant "This can be" from stroke docs of curve and polygon (typst#6715) * Fix curve docs for fill (refer to curve instead of rectangle) (typst#6714) * Add span to `html.frame` node (typst#6716) * Fix return type of `missing_method` (typst#6718) * Encoding fixes for HTML raw text elements (typst#6720) * Update RelativeTo to include tiling in docs (typst#6730) * Add missing "the" for cmyk function of color docs (typst#6731) * Remove use of "last" and "end" for conic gradient circle docs (typst#6733) * Fix broken links in docs (typst#6734) * Simplify links in docs (typst#6732) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Bump hayro and krilla (typst#6741) * Deduplicate fallback smart quotes (typst#6747) * Move `is_inline` to `HtmlElem` (typst#6748) * Move grid cell locator creation to GridLayouter (typst#6746) * HTML whitespace protection (typst#6750) * Improve code snippets in Table Guide (typst#6658) * More accessible color scheme for raw blocks (typst#6754) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Use `stylistic-set: 1` in favor of `ss01` in docs and tests (typst#6766) * Implement fraction styles: vertical, skewed, and horizontal. (typst#6672) * Bump Rust to 1.89 in CI (typst#6775) Co-authored-by: Drodt <daniel.drodt@tu-darmstadt.de> Co-authored-by: Daniel Drodt <132357467+Drodt@users.noreply.github.com> * Fix typo in doc on quotes parameter of smartquote (typst#6779) * Fix logical order in bidirectional lines (typst#6796) * Extract `trim_weak_spacing` function (typst#6797) * Separate items for hyphens, fixing style of repeated hyphen (typst#6798) * Fix Unicode mapping of hyphenation artifacts (typst#6799) * Do not consider default ignorables when picking last resort font (typst#6805) * Compute width of shaped text on-demand (typst#6806) * Fix `sub` and `super` oneliners (typst#6791) * Ensure that hyphenation is possible after a tag (typst#6807) * Make links to `$grid` in `table` docs more specific (typst#6776) Co-authored-by: PgBiel <9021226+PgBiel@users.noreply.github.com> * Fix `repr` of `foo.with(..)` (typst#6773) * Fix case in docs serialization (typst#6808) * Add links and examples in the docs of `str` (typst#6751) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Hash page instead of frame for watch command (typst#6810) * Update nix flake and use nixfmt (typst#6827) * Update & fix tutorial part 3 & 4 example code (typst#6778) * Improve docs on customizing `raw` (typst#6000) Co-authored-by: Malo <57839069+MDLC01@users.noreply.github.com> Co-authored-by: Laurenz <laurmaedje@gmail.com> * Better handle large numbers (u128/i128) in deserialization (typst#6836) * Follow the comment on setting the `State`'s mask (typst#6642) * Allow augment line at the beginning and end of a matrix (typst#5806) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Fix slicing last n elements using count (typst#6838) * Fix auto hanging-indent for centered headings (typst#6839) * Use rust-analyzer from fenix toolchain in flake (typst#6826) * Type safety for logical indices in line layout (typst#6848) * Load linked bitmap images in SVG images (typst#6794) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Fix CJ-Latin space at manual line breaks (typst#6700) Co-authored-by: Laurenz Mädje <laurmaedje@gmail.com> * Allow multi-character symbols (typst#6489) Co-authored-by: Max <max@mkor.je> Co-authored-by: Laurenz <laurmaedje@gmail.com> * Keep end of line whitespace glyphs (typst#6866) * Fix punctuation in HTML placeholder (typst#6854) * Unify and document the behaviours of `{json,yaml,toml,cbor}.encode` (typst#6743) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Improve docs of various numbering parameters (typst#6757) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Document and test `Sides<T>` parameters (typst#6862) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Remove unused `Styles::set_family` (typst#6879) * Make clear that `Content::query_first` is naive (typst#6880) * Ensure correct tag nesting with grouping rules (typst#6881) * Avoid breaking after an empty frame (typst#6335) * Add test for default ignorables before a breakpoint (typst#6782) * Fix typos (typst#6878) * Improve the docs on function params of `array.{sorted,dedup}` (typst#6756) * Add a link from `math.vec` to `math.{arrow,bold}` in docs (typst#6867) * Add a disclaimer about embedding PDFs (typst#6888) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Improve examples in the docs for under/over functions (typst#6889) * Improve docs of `Celled<T>` params of `table` and `grid` (typst#6764) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Fix off by one in tag expansion (typst#6900) * More useful `Debug` impls for `Tag` and `Location` (typst#6901) * Fix potential crash in `Debug` impl of `Property` (typst#6902) * Fix `Debug` impl for end tags (typst#6906) * Make `select_where!` usable outside of typst-library (typst#6910) * Fix footnote links in presence of styling (typst#6912) * Consistently ignore styles for tags (typst#6911) * Expand tags even a bit more around groupings (typst#6909) * Don't warn for zero-sized horizontal spacing in HTML export * Use `singleton!` for `HElem::hole` * Add way to attach role to closest element in HTML export * Add logical parent mechanism to HTML export * Generalize mechanism for root styles to HTML export * Support footnotes in HTML export * Add `default` argument to `array.join` (typst#6932) * Replace the non-existent `$math.arrow` with `$math.accent` in the docs for vector (typst#6918) * Initial Hayagriva bump (typst#6920) Co-authored-by: Laurenz <laurmaedje@gmail.com> * Use different colors for object keys and string-based values in JSON listings (typst#6873) * Support for outline in HTML (typst#6606) * Use Title Case for Doc Pages (typst#6936) * Improve the docs for dictionary (typst#6899) * Add an illustration for `par.{leading,spacing}` in docs (typst#6915) Co-authored-by: Andrew Voynov <37143421+Andrew15-5@users.noreply.github.com> Co-authored-by: Laurenz <laurmaedje@gmail.com> * Initial plan --------- Co-authored-by: Sam Ireson <107627922+samuelireson@users.noreply.github.com> Co-authored-by: PgBiel <9021226+PgBiel@users.noreply.github.com> Co-authored-by: Ian Wrzesinski <133046678+wrzian@users.noreply.github.com> Co-authored-by: cAttte <26514199+cAttte@users.noreply.github.com> Co-authored-by: Andrew Voynov <37143421+Andrew15-5@users.noreply.github.com> Co-authored-by: Laurenz <laurmaedje@gmail.com> Co-authored-by: Tobias Schmitz <tobiasschmitz2001@gmail.com> Co-authored-by: Max <max@mkor.je> Co-authored-by: 3w36zj6 <52315048+3w36zj6@users.noreply.github.com> Co-authored-by: Malo <57839069+MDLC01@users.noreply.github.com> Co-authored-by: T0mstone <39707032+T0mstone@users.noreply.github.com> Co-authored-by: Lachlan Kermode <lachiekermode@gmail.com> Co-authored-by: Y.D.X. <73375426+YDX-2147483647@users.noreply.github.com> Co-authored-by: Ilia <43654815+istudyatuni@users.noreply.github.com> Co-authored-by: Noam Zaks <63877260+noamzaks@users.noreply.github.com> Co-authored-by: Wannes Malfait <46323945+WannesMalfait@users.noreply.github.com> Co-authored-by: Ivica Nakić <ssemigr@gmail.com> Co-authored-by: +merlan #flirora <flirora@flirora.xyz> Co-authored-by: Connor K <sigstackfault@gmail.com> Co-authored-by: Said A. <47973576+Daaiid@users.noreply.github.com> Co-authored-by: Florian Bohlken <flibbo@gmail.com> Co-authored-by: Robin <mewmew@users.noreply.github.com> Co-authored-by: Adrián Delgado <11708972+adriandelgado@users.noreply.github.com> Co-authored-by: frozolotl <44589151+frozolotl@users.noreply.github.com> Co-authored-by: Jassiel Ovando <jassielovando@protonmail.com> Co-authored-by: Patrick Massot <patrickmassot@free.fr> Co-authored-by: Erik <tinger@tinger.dev> Co-authored-by: pog102 <85764555+pog102@users.noreply.github.com> Co-authored-by: Laurenz Stampfl <47084093+LaurenzV@users.noreply.github.com> Co-authored-by: Niklas Eicker <git@nikl.me> Co-authored-by: Marcono1234 <Marcono1234@users.noreply.github.com> Co-authored-by: Igor Khanin <igor@khanin.biz> Co-authored-by: hpcfzl <hopcfizl@gmail.com> Co-authored-by: zefr0x <65136727+zefr0x@users.noreply.github.com> Co-authored-by: Abdul-Rahman Sibahi <asibahi@users.noreply.github.com> Co-authored-by: 枚鴉 <ling@omots.io> Co-authored-by: Myriad-Dreamin <35292584+Myriad-Dreamin@users.noreply.github.com> Co-authored-by: Derived Cat <hooyuser@outlook.com> Co-authored-by: Sebastian Eberle <152992757+sebaseb98@users.noreply.github.com> Co-authored-by: Johann Birnick <6528009+jbirnick@users.noreply.github.com> Co-authored-by: Yaksher <yaksher.git@gmail.com> Co-authored-by: Tau <git@alice-carroll.pet> Co-authored-by: Martin Haug <mhaug@live.de> Co-authored-by: Théophile Cailliau <tjbcg@pm.me> Co-authored-by: Drodt <daniel.drodt@tu-darmstadt.de> Co-authored-by: Daniel Drodt <132357467+Drodt@users.noreply.github.com> Co-authored-by: ultimatile <ultimatile@users.noreply.github.com> Co-authored-by: Poh <167305720+pohlrabi404@users.noreply.github.com> Co-authored-by: Clemens Koza <clemens.koza@gmx.at> Co-authored-by: Siddhant Agarwal <68201519+siddhantdev@users.noreply.github.com> Co-authored-by: Philipp Niedermayer <eltos@outlook.de> Co-authored-by: Toon Verstraelen <Toon.Verstraelen@UGent.be> Co-authored-by: Eric Biedert <github@ericbiedert.de> Co-authored-by: Jan Romann <jan.romann@uni-bremen.de> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>

mkorje force-pushed the parsing-precedence branch from ef7f06d to 95b435c Compare June 25, 2025 06:03

mkorje force-pushed the parsing-precedence branch from 95b435c to dc18182 Compare June 25, 2025 11:25

mkorje force-pushed the parsing-precedence branch from dc18182 to 550c3e2 Compare July 7, 2025 03:02

mkorje added 2 commits July 8, 2025 20:16

Require parentheses in all function-like sub/superscripts

7057809

Add warning

53d13ba

mkorje force-pushed the parsing-precedence branch from 550c3e2 to 53d13ba Compare July 8, 2025 10:19

laurmaedje added this pull request to the merge queue Aug 1, 2025

github-merge-queue bot removed this pull request from the merge queue due to failed status checks Aug 1, 2025

laurmaedje added 2 commits August 1, 2025 10:33

Merge branch 'main' into pr/6442

7a21c5d

Fix formatting

66f1b3c

laurmaedje enabled auto-merge August 1, 2025 08:34

laurmaedje added this pull request to the merge queue Aug 1, 2025

Merged via the queue into typst:main with commit 7dc99e9 Aug 1, 2025
8 checks passed

mkorje deleted the parsing-precedence branch August 1, 2025 10:55

This was referenced Oct 2, 2025

Runtime Math Parsing #7003

Closed

Math mode implicit function call update and parser refactor #7072

Closed

laurmaedje mentioned this pull request Oct 9, 2025

Revert math precedence change #7084

Merged

Uh oh!

Conversation

mkorje commented Jun 13, 2025

Uh oh!

laurmaedje commented Jun 13, 2025

Uh oh!

Enivex commented Jun 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

laurmaedje commented Jun 13, 2025

Uh oh!

Enivex commented Jun 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mkorje commented Jun 25, 2025

Uh oh!

mkorje commented Jun 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

laurmaedje commented Jun 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mkorje commented Jun 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

laurmaedje commented Jul 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

YDX-2147483647 commented Jul 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

A predictable, concise, but inconsistent convention is acceptable

More parentheses, harder editing

Maybe collect more voices?

Uh oh!

laurmaedje commented Jul 8, 2025

Footnotes

Uh oh!

laurmaedje commented Jul 8, 2025

Uh oh!

OverflowCat commented Jul 9, 2025

Uh oh!

laurmaedje commented Jul 9, 2025

Uh oh!

bilgincoskun commented Jul 10, 2025

Uh oh!

surbliss commented Jul 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

NicoWeio commented Jul 20, 2025

Uh oh!

matteosantama commented Jul 26, 2025

Uh oh!

laurmaedje commented Jul 28, 2025

Uh oh!

bilgincoskun commented Jul 28, 2025

Uh oh!

laurmaedje commented Jul 28, 2025

Uh oh!

bilgincoskun commented Jul 28, 2025

Uh oh!

laurmaedje commented Jul 28, 2025

Uh oh!

surbliss commented Jul 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

laurmaedje commented Aug 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Trebor-Huang commented Sep 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

laurmaedje commented Sep 4, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Enivex commented Jun 13, 2025 •

edited

Loading

Enivex commented Jun 13, 2025 •

edited

Loading

mkorje commented Jun 25, 2025 •

edited

Loading

laurmaedje commented Jun 25, 2025 •

edited

Loading

mkorje commented Jun 25, 2025 •

edited

Loading

laurmaedje commented Jul 7, 2025 •

edited

Loading

YDX-2147483647 commented Jul 8, 2025 •

edited

Loading

surbliss commented Jul 20, 2025 •

edited

Loading

surbliss commented Jul 28, 2025 •

edited

Loading

laurmaedje commented Aug 1, 2025 •

edited

Loading

Trebor-Huang commented Sep 3, 2025 •

edited

Loading