3 ms·

The programming parts are very tempting, but I find the philosophy of the math mode input simplification to be questionable. E.g. automatically generating fract

by topaz0 1y ago

The programming parts are very tempting, but I find the philosophy of the math mode input simplification to be questionable. E.g. automatically generating fractions from "/", or removing parentheses depending on whether they are redundant with other grouping. Those are all choices that I want explicit control over, and the most readable choice depends strongly on the details of the expressions. After some digging it's clear that all of that can be overridden without too much effort, but it still seems like a poor default for my use cases.

hkmaxpro 1y ago
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/6672 https://github.com/typst/typst/pull/6442 https://github.com/typst/typst/pull/6442 , see also https://laurmaedje.github.io/posts/math-mode-problem/ https://laurmaedje.github.io/posts/math-mode-problem/
- topaz0 1y ago
  FWIW the second part does not address my concern (which was about omitting literal parentheses that are present in the markup, in some cases), though it is related. Personally I think it's already a mistake for bare/unescaped words to indicate markup, or I guess the intention is that they indicate mathematical semantics and then Typst decides the best way to write down that semantics unless you explicitly interfere -- seems like a recipe for confusion whenever Typst's ideas of the mapping from semantics to typography don't quite line up with yours, or the conventions in your field. I'd much rather approach mathematical typesetting with a typesetting language than a mathematical language where somebody else has decided how that math should be typeset, even if it means a sea of backslashes and curly braces. (Edit to add: I guess this means my preference would be option E from the blog post -- I see the extra symbols as far preferable to the ambiguity between content and markup) Also wow, recovering from this breaking change is going to be incredibly painful for somebody.

by topaz0 1y ago

hkmaxpro 1y ago

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/6672 https://github.com/typst/typst/pull/6442 https://github.com/typst/typst/pull/6442 , see also https://laurmaedje.github.io/posts/math-mode-problem/ https://laurmaedje.github.io/posts/math-mode-problem/

topaz0 1y ago
FWIW the second part does not address my concern (which was about omitting literal parentheses that are present in the markup, in some cases), though it is related. Personally I think it's already a mistake for bare/unescaped words to indicate markup, or I guess the intention is that they indicate mathematical semantics and then Typst decides the best way to write down that semantics unless you explicitly interfere -- seems like a recipe for confusion whenever Typst's ideas of the mapping from semantics to typography don't quite line up with yours, or the conventions in your field. I'd much rather approach mathematical typesetting with a typesetting language than a mathematical language where somebody else has decided how that math should be typeset, even if it means a sea of backslashes and curly braces. (Edit to add: I guess this means my preference would be option E from the blog post -- I see the extra symbols as far preferable to the ambiguity between content and markup) Also wow, recovering from this breaking change is going to be incredibly painful for somebody.