Description
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.
Activity
MDLC01 commentedon Jan 21, 2025
Then, we would probably have to move the ability to create user-defined symbols to Codex as well.
laurmaedje commentedon Jan 21, 2025
I attempted moving this logic while setting up codex, but found it to be not entirely trivial.
T0mstone commentedon Jan 21, 2025
Hm. While I think that that shouldn't be codex's responsibility, not doing this would require some code duplication between codex and typst, which is also really not good.
I'll look into this some more...