Laurenz Mädje

For those interested in typst, Laurenz wrote[0] about the differences between the typst and TeX layout algorithms a while ago. The paragraph layout algorithm is the same but the way it interacts with page placement is quite different. [0]: https://laurmaedje.github.io/posts/layout-models/

I am also not a fan of automatic fraction. BTW, I notice that both of your complaints will be addressed in the next version: https://github.com/typst/typst/pull/6672 https://github.com/typst/typst/pull/6442 , see also https://laurmaedje.github.io/posts/math-mode-problem/

What do you think of this post by Typst's primary contributor? https://laurmaedje.github.io/posts/layout-models/ Do you think it is sufficiently respectful of TeX/LaTeX? As far as proponents go, I will echo the sentiments of many people who have actually used both TeX and Typst: I have been able to accomplish many things in Typst within an hour or two by writing my own Typst code, that in LaTeX I could only accomplish after several days by cargo-culting indecipherable gibberish from years-old forum posts. I freely admit Typst can't (yet) match LaTeX's long-tail package ecosystem, but it is much more pleasant to use and easier to reason about.

No, they are not using the same algorithm: https://laurmaedje.github.io/posts/layout-models/

After reading Laurenz's blog post on TeX vs Typst layout [1], it made me wonder: how hard would it be at this point for them to make Typst directly understand TeX, and let you insert chunks of TeX. It would make for a really nice upgrade path. Of course, being bug-for-bug compatible once people layer on tons of TeX packages seems like a losing game. But if most straightforward TeX stuff "just worked", it would be an easy way to upgrade one paragraph at a time… [1] https://laurmaedje.github.io/posts/layout-models/

Typst handles hyphenation very similarly to TeX. https://github.com/typst/hypher https://laurmaedje.github.io/posts/hypher/

I wonder how this compares to comemo [1] [2], they're both memoization frameworks with "tricks" to limit invalidation. The trick in comemo's blog post is to make the dependencies fine-grained, by tracking and only comparing what parts of them are actually used; while the trick here is to have functions depend on other outputs instead of the root input, so changes don't propagate all the way (+ laziness). But I'm sure some comemo functions are memoized on incremental computations, and salsa has some way to e.g. not recompute the entire AST when the source code changes. I suspect there's also an issue where most incremental computations tend to invalidate way more than they need to; like if someone accidentally creates a function which takes a big array and an index, and only access the element at or a few elements around that index, but the anything in big array changing will cause it to be recomputed. So is there a system to profile what gets recomputed every time a query is run? [1] https://laurmaedje.github.io/posts/comemo/ [2] https://github.com/typst/comemo