[msravi]

I have only two peeves with typst.

1. They should have carried forward the latex standard as-is for math, instead of getting rid of the backslash escape sequence, etc.

2. There is no way to share a variable across a file's scope - so can't have a setting that is shared across files - not even with state variables.

Other than this, typst is solid, and with the neovim editor and tinymist lsp, is great to write with.

[cbolton]

Regarding point 1: I'm so glad they didn't keep the math syntax, there's finally progress in math text input! E.g. we can now write

  $
    ZZ &= { ..., -1, 0, 1, ... } \
    QQ &= { p/q : p, q in ZZ }
  $

  $
    a = cases(
      0 & quad x <= 0,
      mat(1, 2; 3, 4) vec(x, y) & quad x > 0
    )
  $

instead of

  \begin{align*}
    \mathbb{Z} &= \{ \dots, -1, 0, 1, \dots \}, \\
    \mathbb{Q} &= \left\{ \frac{p}{q} : p, q \in \mathbb{Z} \right\}
  \end{align*}

  \[
    a = \begin{cases}
      0 & \quad x \leq 0, \\
      \begin{pmatrix}1 & 2\\ 3 & 4\end{pmatrix}
      \begin{pmatrix}5\\6\end{pmatrix} & \quad x > 0
    \end{cases}
  \]

Regarding point 2: you can put your settings in a file `settings.typ` and import it from multiple files.

[msravi]

> Regarding point 2: you can put your settings in a file `settings.typ` and import it from multiple files.

Let's say I have 3 flavors of settings and 10 different typ files - normally I'd just have 3 flavors of top.typ (top1.typ, top2.typ, top3.typ) with the correct settings for each flavor with settings proagated to all 10 files. Compiling top1/top2/top3 would then create flavor1.pdf, flavor2.pdf, and flavor3.pdf

Now how do I do it with settings1.typ, settings2.typ and settings3.typ? I have to go into the 10 different files and include the appropriate settings file! Or employ hacks like creating a common settings.typ using bash in the Makefile and including the common settings.typ in the 10 different files.

Edit: This is an actual use case - I'm helping with a resume, and have 3 different resume styles - a resume, a cv, and a timeline - and different files like education, work experience, honors, awards, publications, projects, etc and the level of detail, style, and what is included or not in each is controlled by which resume style is active. In latex I did this using \newcommand and the ifthenelse package.

In typst, I have had to resort to passing these global settings as arguments to functions spread across these different files, so each resume item (function) instantiated from the top file has a bunch of parameters like detail_level = 1, audited_courses = true, prefix_year = false, event_byline = true, include_url = true, etc., which make the functions unweildy.

[cbolton]

Just have a master settings.typ that you import in top1.typ, top2.typ and top3.typ?

Alternatively, you can pass global settings at build time with `typst c --input name=value`

Maybe I misunderstood though, if you can link to an actual example (gist or something) I'd be happy to try and give a concrete solution.

[msravi]

> Just have a master settings.typ that you import in top1.typ, top2.typ and top3.typ?

Yes, but each included file (like education.typ, publications.typ, etc) should also get these settings propagated from top - which typst doesn't allow - the appropriate settings need to be included in each of these files.

> you can pass global settings at build time with `typst c --input name=value`

This is something I did not know - will check.

[cbolton]

You can import settings.typ in top.typ, and then import top.typ in education.typ. This way the variable/function definitions will propagate.

Or you can import settings.typ in all files that need it (education.typ, etc.).

What doesn't work is to have a file like top.typ contain

  import "settings.typ": *
  import "education.typ": *

and hope that this will make settings available in education.typ. Because each .typ file is "pure" in the sense that it only knows the variables/functions that are defined in the file, or imported. This way you don't have a file magically affecting the bindings available in another file, which is nice.

It's true there are cases where you'd like something like the above. Currently you can do something like that using states and context (basically putting the "settings" into the document and retrieving that) but it's not so nice. In the future the plan is to make this nicer by allowing custom type definitions (and having show rules and set rules work with them as they work with built-in types).

[davemp]

Agreed. I’ve done a far bit of math in both and typst’s choices are way more memorable and ergonomic.

It’s not like keeping the syntax would really gain typst anything besides folks not having learn new things.

[aragilar]

You could use unicode-maths?