-
-
Notifications
You must be signed in to change notification settings - Fork 12
Implement optional modifiers #105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
This improves type safety to prevent bugs like the one also fixed here (best_match_in still contained a wrong call to `contains`)
This looks great! The list shows how useful this is to avoid ambiguous cases that would easily break in the future. For the globe it is a bit unfortunate as it makes sense to write Maybe a solution would be to define
and have the validation code recognize that |
Yes, that's what I meant with "duplicating the variant". Tho your example wouldn't work since
The issue with this is something that ties into the next thing I want to talk about here (see my comment below this). |
These changes to Now my point here is that I actually think exposing this is a good thing and we should give typst users access to the new resolution system too, so custom symbols aren't second-class citizens. In codex, we can just run the test
|
Another small thing that confused me a bit (and why I had to double-check that |
I think a fast implementation in Typst should be possible. To detect overlaps it should be sufficient to populate a dictionary where the keys are all "aliases" of all variants. The initial list of keys could be generated statically when building the Typst executable. Then checking overlap for a new symbol would just be a dict insertion for each new alias (negligible runtime) which would fail if the key already exists (unless I'm missing something and the check must be more sophisticated?). |
Keeping a dict might be fine in practice, but it does have exponential space complexity in the worst case ( |
If that's a concern, what about an algorithm that dynamically generates a dict for the symbol under consideration? I.e. when the user wants to define |
That's already what I meant. But I suppose the memory usage isn't actually that bad for all sane applications... |
Closes #51.
This is mostly done, but there are some unresolved questions and some issues and it still needs some finishing touches like documentation, which is why it's a draft for now.
This is also a breaking change since it changes the way
ModifierSet
works, so I should probably remember to bump the version inCargo.toml
before we merge this.Changes to observable syntax
The way I've implemented it, the
modifier?
syntax applies directly in theModifierSet
, so it would be exposed to the users in typst too. (Or typst would have to do some extra sanitizing).And also, it's not really clear how this whole new resolution algorithm would interact with user-defined symbols from typst: I've kept the code in
best_match_in
mostly the same for now, but we could strip it down way more if the match was actually guaranteed to be unique. (But of course, this may not be true for user-defined symbols.)Changes to variant resolution
I have another branch where I wrote some ad-hoc code (mostly identical to what is now the
no_overlap
test) to brute-force check every possible modifier set for every symbol and generate a list of which ones differ between the old algorithm and the new one.This is that list:
emoji.globe
where a variant has two optional modifiers, of which at least one needs to be present since it is not the default variant. This could in theory be encoded by duplicating the variant, but that'd be observable in the repr and also a bit hacky, so I haven't done it for now.Other stuff
I have some other minor things I'd like to say, but I'm too tired now, so I'll add them later.