laurmaedje

It seems to have started slowly. For me, Github releases have failed to serve requests for hours already.

The backslashes are not really relevant to the problem discussed in the post. The ambiguity between symbols and argument-taking macros exists just the same in LaTeX. Consider:

    $ f_\abs{x} $
    $ f_\pi{x} $

LaTeX just happens to do what the post calls "runtime parsing" because LaTeX doesn't really distinguish between different compiler stages at all. If you look at a macro, you can't know whether it will eat up the following braced argument.

In fact, not using backslashes for symbols can actually give an _edge_ with this problem because it would allow distinguishing `pi` and `#abs` (option E in the post).

(Author of the post and issue comment here.)

The preferences there were honestly rather ad-hoc w.r.t to the pull request and the approach the pull request took. And (as the author laid out), the PR was a rather ad-hoc solution for a problem we discovered literally one night before Typst 0.14 was supposed to be released.

The design thoughts there were a bit half-baked, which is why we've closed the PR and reverted the original change, to get more time to properly reconsider things.

The math syntax has seen little change since Typst's initial release (except for the infamous precedence change in 0.3 that triggered all this) and just has some quirks that haven't been properly ironed out yet. However, it will remain a focus now and we want to give it a proper cleanup.

While not really related to the math topic, let me answer this:

- You can add an arbitrary number of trailing `[..]` blocks and they are just trailing arguments. So 2 & 3 are really the same.

- 3 & 4 are different because argument lists may _never_ have a space before them in Typst. you can also not write `calc.min (1, 2)`

The reason why the space may not be added is that you can write

    #for x in range(5) [
        Value is #x
    ]

And `range(5) [..]` therefore needs to be different from `range(5)[..]`. This aligns with normal formatting conventions and I haven't seen this become a problem in practice.

As one of the core developers, I would say "stubbornly sticking to their interpretation" is not entirely fair. I am open to changing this, but I don't want to do it hastily --- because that means changing things twice. Figuring out all the correct behaviours, in particular with equations and inline objects, is challenging. I tried to constructively present some arguments in favor and against the proposed changes in the linked issue, but I simply did not have time to push things forward beyond that myself so far.

(Typst dev here.) That's one of the next big things we plan to work on once Typst 0.12 has shipped. :)

If you're talking about weak widow/orphan support for headings in particular, that will finally be fixed in Typst 0.12.

Hey, I'm one of the Typst devs and author of the issue.

The reason there is no logging yet is because we want to get it _right_ rather than landing a permanent temporary solution. And there were simply more urgent things to do so far.

Also note that if you use an LSP or the web app, you can inspect the live values in your code simply by hovering over them.

Good point! lr should support lengths in addition to ratios. Should be easy to add.

Hey, Typst dev here. Regarding HTML export: It's not bikeshedding. It's more that, while we consider HTML as pretty important, we decided that fixing and improving the layout engine first was even more important. Basically getting what we have already right before starting to do more stuff.

That said, our plans for HTML export have definitely become more substantiated and concrete over the past year and once the current work on layout finishes, it is the next big thing on our list.

Those are supported, too.