Adjustable greed in math parsing?

General
1

I’ve been using typst for a while and by far the biggest point of frustration for me has been the parentheses being too greedy, especially around subscripts and superscripts. For example, i absolutely never ever want f_n(x) to be implicitely parsed as f_(n(x)). I never want p_1' to mean p_(1') but always p'_1. This issue arises everywhere with parentheses. I absolutely never want 1<=(2+3)/4 to mean 1 (<=(2+3))/4 but always 1 <= (2+3)/4.

I’m aware adding a space breaks the fusion of the parentheses with the previous symbol but this just makes writing unnecessarily tedious and error-prone. Is there a way to adjust this behavior ?

2 Likes
2

There is already Different parsing in maths mode with single-digit vs. multiple-digit numbers · Issue #4828 · typst/typst · GitHub for $1/2(x)$ ($1/2 (x)$) and $1/10(x)$ ($1 / (10(x))). So for your examples, if there are no open issues, you can create one.

You can always just do this instead:

$f_n (x)$ \
$p'_1$ \
$1 <= (2+3)/4$

In fact, for the last one, I would normally use all spaces:

$1 <= (2 + 3) / 4$

But for the first two, it’s indeed more intuitive to write $f_n(x)$ and $p_1'$, because it’s an edge case for $f(x)$ and $p_1$, which have only one correct & visually accurate format.

3

Many agree the current rules for _ and ^ are broken… There’s a good chance that this will be changed to do what you want :slight_smile:

Yeah maybe this could be adressed at the same time as the previous point…

This is already how it works. Did you have another case in mind?

I agree the current parsing rules should be improved, but please no “adjustable greed” or other ways to customize parsing. Imagine if every piece of Typst code you read (documents written by colleagues, snippets on the Internet) assume different parsing rules. That sounds like a nightmare. I’d have to translate other people’s Typst code to my parsing rules before I can use it. As if it was a different language like LaTeX. Please no. Let’s have a common base language, common parsing rules. We can already customize a lot with local variables/functions and show rules.

4 
$1<=(2+3)/4$

image

5 
$1<=(2+3)/4$

image

I’m on Typst 0.13.1 dev version.

1 Like
6

You are on a dev version. But that means one out of 3 problems solved.

1 Like
7

Damn you’re right! My test document was being compiled by a typst watch process that had been started before I replaced the executable with the 0.13.1 release :slight_smile:

8

To prove this point – you could (although I don’t recommend it) change the f_n(x) behavior like this:

// replace all attach occurrences (a_b, a^b, etc.)
#show math.attach: it => {
  // we'll need the sequence content type
  let sequence = [].func()
  
  // extract base and bottom attachment
  let (base, b, ..fields) = it.fields()
  // if the bottom attachment is not of the form b(c), don't do anything
  if b == none or b.func() != sequence or b.children.len() != 2 or b.children.last().func() != math.lr {
    return it
  }

  // separate b and (c)
  let (b, next) = b.children
  // recombine to the form a_b (c)
  $attach(base, b: #b, ..fields)next$
}

$f_n(x)$

(made this recently on Discord for someone else)

But adding outright parsing customization, apart from being hard to pull off and definitely impacting performance, seems like it would be too much.

1 Like
9 
#let sequence = [].func()
1 Like