As it stands now, the concept of a "modifier" doesn't really exist in codex itself. It only knows about variants. The closest thing is the syntax validation in build.rs (and the partially applied modifier alias code from #27).
Despite the decision from #5 (comment) that codex shouldn't really aim to be independent for now, I think the code to resolve "symbol accessors" should be in codex instead of typst, so that the way modifiers work is formalized at our API boundary.
The way I envision this would be a get(&str) method on Symbol, so that you could resolve e.g. lt.eq by finding the lt symbol and calling get("eq") on it.
As it stands now, the concept of a "modifier" doesn't really exist in codex itself. It only knows about variants. The closest thing is the syntax validation in
build.rs(and the partially applied modifier alias code from #27).Despite the decision from #5 (comment) that codex shouldn't really aim to be independent for now, I think the code to resolve "symbol accessors" should be in codex instead of typst, so that the way modifiers work is formalized at our API boundary.
The way I envision this would be a
get(&str)method onSymbol, so that you could resolve e.g.lt.eqby finding theltsymbol and callingget("eq")on it.