Skip to content

Resolve modifiers #30

Closed
@T0mstone

Description

@T0mstone
Collaborator

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

MDLC01 commented on Jan 21, 2025

@MDLC01
Collaborator

Then, we would probably have to move the ability to create user-defined symbols to Codex as well.

laurmaedje

laurmaedje commented on Jan 21, 2025

@laurmaedje
Member

I attempted moving this logic while setting up codex, but found it to be not entirely trivial.

T0mstone

T0mstone commented on Jan 21, 2025

@T0mstone
CollaboratorAuthor

Then, we would probably have to move the ability to create user-defined symbols to Codex as well.

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...

added
metaDiscussion about the structure of this repo
on Jan 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestmetaDiscussion about the structure of this repo

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      Participants

      @laurmaedje@T0mstone@MDLC01

      Issue actions

        Resolve modifiers · Issue #30 · typst/codex