Codex

[grizzled granite]

I should have time to look over the proposals very soon (thanksgiving week)

[midnight tangle]

As a reminder, here is the link to the Symbol Proposals document: https://typst.app/project/riXtMSim5zLCo7DWngIFbT. There are many other proposals that still need some thoughts before making PRs.

[past python]

@midnight tangle I would propose to proceed with codex as follows:

• PRs that just adjust symbols could be merged with 2 approvals from trusted community members that are involved in the symbol discussions. I could try to come up with a list of potential people later and they can decide whether they'd be up for it. (Being one of these people wouldn't imply the need to review the PRs, just that if two people review & approve it, it could be merged without further action from my side.)
• I'd still like to be pinged in PRs with breaking changes
• And PRs that touch the code, I would continue to review

[midnight tangle]

I think this would work

[past python]

@midnight tangle @grizzled granite @storm whale @pastel violet @lapis moth @heady fulcrum
As mentioned above, we'd like to experiment with a more community-driven approach for expanding Typst's set of named symbols. If you are interested in helping with that, I'd like to invite you to the new typst/codex GitHub repository and give you the ability to approve pull requests. Two approvals (excluding any from the PR author themselves) will allow a PR to be merged. Note that even if you accept this, there is of course no requirement to be active and review PRs, you just have the ability to do so. If you are up for it, please let me know and I'll add you!

[heady fulcrum]

I'd be happy to help. To be honest, I'm not sure how active I'll be able to be, but that can be calibrated over time, and I would like to contribute more on this front 🙂

My GitHb username is the same as in here, dccsillag

[grizzled granite]

I don't mind, and you should already know my GitHub username.

[lapis moth]

I probably won't be very active, but I'm happy to be trusted and this might also be a good way to contribute a bit more. My GitHub username is T0mstone.

[past python]

I added the four of you. Let me know if there are any problems with the branch protection rule. It's the first I've configured such a complex rule.

[pastel violet]

Hey! It's been a short while since I've been active around the community but I'd love to join in! I reckon Github issues might really help separate many discussions that we had here
I'm emilyyyylime on github

While I'm here, would anyone like to catch me up on the work done on Symbols lately? Maybe point me to areas around the symbols doc that I should read up on?

[pastel violet]

Would love input in https://github.com/typst/codex/issues/5

[midnight tangle]

Not much has happened appart from the creation of Codex. You can read the proposals (I have added some) and give feedback here.

I also added more symbols to the Drafts section (but I don't have a list, sorry)

[pastel violet]

Good to know, I'll try to find time to look over it

Figures you'd get nothing done around here without me 🙄
xD

[storm whale]

I'd also be happy to help with that! I'll try my best to be reasonably active on this front. mkorje is my username on GitHub as well.

[midnight tangle]

I just merged the first proposal into Codex ! Proposal 4, in #4. 🎉

[midnight tangle]

Does anyone have an opinion on whether we should have interleave.not for ⫵?

[storm whale]

I think struck is more consistent than not for the horizontal stroke

[midnight tangle]

To be clear, we could add both

[pastel violet]

I think it makes more sense to leave struck as the only name

no real reason to call it not, especially since it's an operator and not a relation

[midnight tangle]

Oh right i did not think of that

[grizzled granite]

It's also a horizontal bar and not slanted like in typical "not" symbols

[pastel violet]

Should the Proposals Doc (https://typst.app/project/pHN_iIPjeuCyI_N2JZB84o) be linked in codex's README?

tbh I don't know if there's that much use in it given the tools inherent to a Github repo

I guess it will always be useful to have a disorganised list of yet-unmapped symbols

for which purpose I figure having it front and centre in the readme makes sense

[midnight tangle]

I was thinking about that recently. Now that we have a separate repo, we can create more PRs without flooding typst/typst. The document is still useful as a list of symbols with some thoughts, but we could use PRs instead of proposals now (especially because implementing any given proposal is often trivial). The advantage of the document is that proposals there are laid out in a cleaner way, with tables. But if this is the only advantage, this can be recreated in PR descriptions in Markdown.
Either way, it would probably make sense to link the document in a Contributing section in the README.

[pastel violet]

sounds good. I also like the more open nature of PRs for discussion

[grizzled granite]

I don't really like using PRs for discussion

[midnight tangle]

Why so?

I feel like for discussions about small proposals they would be fine. Of course, discussions that happen before creating proposals would probably be easier to have here.

[grizzled granite]

That's my point. Most discussions should be finished before the PR is even created

[pastel violet]

sure, that can happen in issues or Github discussions

but the compartmentalisation of issues is a big plus compared to Discord

and The Document has the downside of requiring full editorial permissions

[midnight tangle]

And the webapp's comments are less practical than Discord or GitHub in my experience (no notifications when someone answers something for example)

[pastel violet]

For #6, would you prefer comments or directly appending the name:
a)

// Control.
wj   U+2060 // Word joiner
zwj  U+200D // Zero width joiner
zwnj U+200C // Zero width non-joiner
zws  U+200B // Zero width space
lrm  U+200E // Left-to-right mark
rlm  U+200F // Right-to-left mark

// Spaces.
space U+20 // Space
  .nobreak U+A0 // No-break space
  .nobreak.narrow U+202F // Narrow no-break space
  .en U+2002 // En space
  .quad U+2003 // Em space

b)

// Control.
wj   U+2060  Word joiner
zwj  U+200D  Zero width joiner
zwnj U+200C  Zero width non-joiner
zws  U+200B  Zero width space
lrm  U+200E  Left-to-right mark
rlm  U+200F  Right-to-left mark

// Spaces.
space U+20  Space
  .nobreak U+A0  No-break space
  .nobreak.narrow U+202F  Narrow no-break space
  .en U+2002  En space
  .quad U+2003  Em space

I think I'm leaning towards the latter to make it obvious that this is machine-read (if the relevant feature is enable) and not just meant for people

Also I've noticed dot.triple is U+20DB Combining three dots above. This feels... out of place? I didn't think we currently have symbols defined for combining characters (though I do think that would make sense under a new module combining!), for applying modifiers we have callable symbols, which usually don't expand to a combining character when used on their own... Is this done because there isn't really a non-modifier counterpart to U+20DB?

actually same for dot.quad (U+20DC resp.)

[midnight tangle]

Is this done because there isn't really a non-modifier counterpart to U+20DB?
Probably, but I don't know.

[midnight tangle]

Option b) is incompatible with the current syntax: how would you know where the name ends?

[pastel violet]

end of the line

the current syntax is line-based

[midnight tangle]

No

[pastel violet]

oh is just the parsing

[midnight tangle]

Wait actually I don't know how the parser is implemented, but the current syntax can be parsed without relying on linebreaks

[pastel violet]

No; looking at the parsing code in build.rs the syntax is definitely line-based

[midnight tangle]

Ok

[pastel violet]

That seems to be true but I see no reason to keep it this way

[midnight tangle]

I do still prefer option a). It feels weird to have text that is not a comment, but is just ignored unless you explicitly enable a specific feature flag.
But this isn't a strong opinion.

[pastel violet]

You mean a) then?

we could also do something else like

zwj  U+200D "Zero width joiner"

This one is also quite good I think

[midnight tangle]

Sorry, yes this is what I meant

I guess what I like with option a) is that this makes it more obviously optional, and then it would just be "we have a test that makes sure when a comment contains a Unicode name, it matches that of the character that is on the same line"

[pastel violet]

You could see it like that

I was thinking of it more like "we include names for verification, but because the dependency is rather heavy, we gate the verification under a feature-flag"

Also I'd like it to be possible to add comments after the names for whatever reason

[midnight tangle]

that's a good point

[pastel violet]

Is this worth deeper discussion or should I just do what I think?

[pastel violet]

(not that that would be that hard to parse, just might be non-obvious to someone writing the code)

[midnight tangle]

It doesn't matter that much in the end. Just implement it, and the exact syntax can probably be discussed in the PR

[pastel violet]

Already did 😛

[midnight tangle]

I think it would make sense for it to be a test rather than a feature flag, though. Because I don't see why the users of Codex would want to enable it

[pastel violet]

even if it's a test it would be locked under a feature flag to avoid pulling in unnecessary dependencies, so I don't see why not just do it always then

Oh that can be done with dev-dependencies

I see

Where would those tests lie though 🤔 because it's rather a lot easier to just add some 20 lines to build.rs than having to reparse the entire file in a test suite

[midnight tangle]

Can you add tests in build.rs?

[pastel violet]

I wouldn't think so, but it's worth a check I guess

yeah I don't think so

but it's really very minimal overhead, especially compared to the size and transitive dependencies of unicode_names2

[midnight tangle]

that's sad

[pastel violet]

But actually I don't see a way to make this into a dev dependency without reparsing the files

This would jive with an extra crate for parsing, but that sounds a little much

[midnight tangle]

Do you mean the parsing code would have to be duplicated?

If so, then I think the best is to just do whatever is easier as long as the default is to not have any dependency

[pastel violet]

Yes

[pastel violet]

Or even worse; a C-style include file. So we can include! it from both build.rs and test/sometest.rs

[midnight tangle]

Magnificient!

[midnight tangle]

Two symbol-related issues from typst/typst should probably be transferred to typst/codex :

• Filled circles are out of order #2755
• Support for U+2129 (Turned Greek Small Letter Iota) #5355
  Additionally, #3915 could also be transferred to typst/codex, but I'm not sure.
  Cc. @grizzled granite since I believe you have the necessary permissions to do that.

[grizzled granite]

I can check later, but I honestly doubt it

The triage role is pretty limited

[midnight tangle]

Sorry for the ping then

[grizzled granite]

No worries

[midnight tangle]

@past python you seem to be back, so I'm taking the liberty to ping you to bring your attention to this

[past python]

done

[midnight tangle]

thanks!

[lapis moth]

could you invite me again? I've had no internet for the past 2 weeks (it's finally back now!) and the invite has sadly expired.

[past python]

done

[lapis moth]

thanks!

[pastel violet]

Is that due to the hurricane? Hope you're okay!

[lapis moth]

Thanks but it's nothing that serious. I just moved and they had me wait this entire time

[pastel violet]

oh that's less extreme :v)

[lapis moth]

Also I don't think we get hurricanes here in Germany🥸

[pastel violet]

Yeah I don't try and remember who lives where on Discord

[lapis moth]

fair

[midnight tangle]

This was already briefly discussed here #1277628305142452306 message, but I would like more feedback before implementing this proposal. In particular, do you prefer intersection (or even the current sect) over the proposed inter?
Additionally (but this is more of an implementation detail), we my want to also keep sect for a while to give people the time to change it (this is probably a highly used symbol). Alternatively, we may decide to postpone this change until we have a way to deprecate symbols (as suggested in #2 (comment)).

[past python]

I strongly prefer inter. The full intersection is just too long. A migration period seems well-advised indeed.

[lapis moth]

not sure how necessary a grace period is when you can just put #let sect = sym.inter at the top of your file in 10 seconds.
I don't mean to say that keeping sect for a while isn't a nice thing to do, just that this is also something to consider.
Also, I'd personally think breaking things here would be fine since we're not 1.0 yet and you'll have to be prepared to fix things when upgrading anyway.

[past python]

The fact that we do breakages doesn't mean that we shouldn't make them easier to deal with when it's reasonably easy for us.

[lapis moth]

yeah, that's what I was getting at with the second sentence👍

[midnight tangle]

For those interested, these notes from the Codex Symbol Proposals document are related to #5492.

On a side note, it may make sense to move the implementations of math.italic, math.bold, math.bb, etc. to Codex.

[lapis moth]

Do we want to have a module with all the country flags? Or maybe just the regional indicator symbols? Or maybe even a function that takes a country code and converts it to them?

[grizzled granite]

The flags are emojis. I'm not sure if emojis are supposed to be a part of codex as well

[lapis moth]

They already are

https://github.com/typst/codex/blob/main/src/modules/emoji.txt

[grizzled granite]

I see

[midnight tangle]

I was thinking we could have a flag function in emoji that accepts a regional code as a string, and returns the corresponding flag.

Oh that was your last suggestion

[balmy bison]

I think that’s the best option, since otherwise, determining which flags to include becomes politically contentious

[midnight tangle]

Moreover, it makes this future-proof due to the way flags work with Unicode (good job, Unicode!)

By the way, I have added multiple proposals to the document. I don't exactly remember which I already posted here but i think these are the ones.

[lapis moth]

Wait |-> has a long form and we don't have |-->?????

This needs to change

[midnight tangle]

Oh the shorthand is a piece of context that I should have added! Thanks.

[grizzled granite]

There is a sort of moratorium on shorthands because parsing is a nightmare

[midnight tangle]

Regarding the proposed |-->, the problem with shorthands is that they can quickly become annoying. For instance, someone could write $|x|-->_(x->+oo)+oo$ and reasonably expect a long arrow without a bar

[grizzled granite]

As I've said before this is a fixable issue though. You just need to impose stricter rules about how shorthands can be used

[lapis moth]

well, sure, the same applies to |->

and tbh typing |-> is kinda annoying anyway

[midnight tangle]

Yes, but |-> is more common, so this is a question of where we draw the line. But I agree at some point we may have to think more about shorthands

[grizzled granite]

Probably best to wait until there's a more comprehensive overhaul of math

There's a lot of stuff that needs improvement

[heady fulcrum]

I strongly believe that |-> should stay

And people should be using abs(x) instead of |x| anyways. Though this could be a lot more discoverable......

[grizzled granite]

I'm not advocating for its removal

[heady fulcrum]

BTW, just stumbled into the fact that tilde.equiv is apparenty not discoverable from eq? Or did I miss something?

Feels like it should be available as something like eq.tilde or eq.sim

[midnight tangle]

Composite symbols are usually named from top to bottom. eq.tilde would be an equal sign above a tilde.

[lapis moth]

yeah I can't say I love this but I don't have a better idea either

[pastel violet]

similar/isomorphic or some such is not a terrible idea

[grizzled granite]

The problem is that while names like that are useful when the meaning is fairly universal, it's unfortunate if it's not

[midnight tangle]

In this case, similar or isomorphic could be an additional name (i.e., not replacing the current tilde.equiv). So other use cases can continue using tilde.equiv.

[grizzled granite]

I don't think similar is good, since \sim in latex is a completely different symbol

if you want to add something like this we need to investigate more

there are many symbols that are used for isomorphisms

[lapis moth]

I have it as isom

[midnight tangle]

Someone opened a PR to add ≒ and ≓. I've given my feedback for the names under the PR.
https://github.com/typst/codex/pull/16

[midnight tangle]

Following #1277628305142452306 message.
Even though there is currently no way to deprecate sect, I implemented Proposal 14 in #17. sect is a widely used symbol, so I believe the sooner we make its new name available, the better. I also had multiple friends ask me why sect was used instead of inter, which illustrates that at least some people would start using inter instead of sect even without a deprecation warning.
If I have the time in the following weeks, I may try to implement a way to deprecate constants in Typst (I don't know how hard this would be).

[grizzled granite]

I want to engage in this stuff but recently I've been so busy 😦

[midnight tangle]

Don't worry. There is still a lot of work to do, so you will likely have something to do when you have the time

[solemn scarab]

A few days ago I wanted to use the micro symbol, I searched for micro, mi, my but the real alias was mu. I'm not a native English speaker but it did not seem intuitive to me.

[grizzled granite]

mu is the actual name for the letter

[storm whale]

I think this might be a good idea, moving the functions that style a char to codex.

I've also learnt that there is a way to have both calligraphic and script styles in math using variation selectors

[grizzled granite]

Unfortunately it's font dependent

And even if a font has both, the way to enable them varies from font to font

So short of maintaining a database of how to make the switch in various fonts I'm not sure how to approach that

[storm whale]

I dont think this is font dependent tho, its font dependent whether it has added it, but Unicode has it as a standardised variation sequence

Some more context https://www.unicode.org/L2/L2020/20275r-math-calligraphic.pdf

[grizzled granite]

The document refers to it as a proposal

[storm whale]

Its been accepted

Thats just the only place I can find a nice explanation of it

https://www.unicode.org/Public/UNIDATA/StandardizedVariants.txt

[grizzled granite]

Doesn't really help unless fonts actually adopt it though

[storm whale]

True

but still its promising

much better than the stylistic sets

[grizzled granite]

Yes. Making them occupy the same codepoints was dumb in the first place.

[storm whale]

I'll probably contact NewCM maintainer and suggest it

[grizzled granite]

Is this a part of Unicode 16.0 then?

[storm whale]

I think it was 14.0 actually

[grizzled granite]

You're right

[grizzled granite]

Are there any fonts currently supporting this?

[storm whale]

I found it mentioned in the MathML Core spec, and have since seen MathJax and LatexML have issues open for this

[storm whale]

Not that I know of, but there is no harm in adding the variation selector chars as it'll just fall back to whatever the font has

[grizzled granite]

You know except for people complaining when scr(F) doesn't work 😛

Should make issues for all the major math fonts then.

[storm whale]

We'll make sure then to add a disclaimer in the docs aha

Another caveat is that this is only officialy for the upper case latin alphabet: quoting from the proposal tho

Note that since the lower-case script letters look almost the same in chancery and roundhand, lower-
case script letters do not need to be distinguished and we don’t give variation sequences for them. We
have not seen contrastive usage of lower-case chancery and roundhand script letters. Nor have we seen
contrastive usage of math bold script letters and we don’t give variation sequences for them either.
Nevertheless, a font vendor might want to include complete sets of these characters in the event that
word processing programs want to display math script letters with uniform styling

[grizzled granite]

Why Unicode

Why make exceptions? It just complicated things

[storm whale]

They should've just added codepoints for both from the start

[grizzled granite]

Does this mean a font can't do the lowercase if it wants to?

[storm whale]

No, I think it means a font can

though it is up to the processing program on whether to actually apply it, i guess

[grizzled granite]

Ok

It would make no sense to not make it work even on lowercase then

[storm whale]

I haven't checked completely yet, but maybe some programs when shaping the text won't apply the variation selector if its not listed in https://www.unicode.org/Public/UNIDATA/StandardizedVariants.txt ? (at least, that is the only scenario I can think of where it would not work)

[grizzled granite]

Maybe, but typst can make a choice

[storm whale]

yeah exactly, so shouldnt really be a problem then

[midnight tangle]

I'm a bit late, but there is also the bottom of this chart: https://unicode.org/charts/PDF/U1D400.pdf

Also in the Unicode Core Spec: https://www.unicode.org/versions/Unicode16.0.0/core-spec/chapter-22/#G82733

[midnight tangle]

Unicode has a separate character for micro (separate from the lowercase Greek letter mu): U+00B5 µ. Quoting the Unicode Core Spec, "The same equivalence [canonical equivalence] does not exist between micro sign and mu, and use of either character as a micro sign is common. For Greek text, only the mu should be used."
We may add micro for micro sign later, but in the meantime, you can use mu to insert the Greek letter instead.

[storm whale]

Truly baffling how inconsistent the recommendations are on using these unit symbols

[midnight tangle]

They are mostly based on usage I think.
The micro sign is accessible on my AZERTY keyboard, so it's use is probably much more widespread than for the ohm sign.

[storm whale]

Ahhh I see that makes more sense

[grizzled granite]

@storm whale it's apparently already fixed in Stix Two Math. Unfortunately only in the non-public development version that's seemingly never being released...

https://github.com/stipub/stixfonts/issues/218

[storm whale]

At this rate I don't expect an update to ever come

[grizzled granite]

https://github.com/stipub/stixfonts/issues/227#issuecomment-2132410296

there's still hope I think, just moving at a glacial pace

[storm whale]

They really seem beholden to STI Pub

Off topic but are they the organisation that runs stix made up of a bunch of companies and publishers?

[grizzled granite]

it's sad, because it's really the most complete math font that exists

as far as I know

[grizzled granite]

it's a consortium yes

https://www.stixfonts.org/#sti

ok the link didn't work, but you can click the "sti pub companies" top right

[storm whale]

Ah I see

Reading the comments in that issue it really does come across as though the consortium's work has kinda stalled

A shame

[grizzled granite]

https://github.com/stipub/stixfonts/issues/270

does typst handle the soft_dotted feature?

it's not clear to me whether it's intended for use in math fonts, but in the prop list several math symbols are in fact listed

[storm whale]

I don't think so, and I don't know anything about that. Its basically just i and j and its variants that we switch in the dtls opentype feature for accents

[grizzled granite]

The list has way more symbols than that though

[storm whale]

I think it'd make sense to use this still tho then

[grizzled granite]

At least as an option. It would make using dotless i-s more convenient, since you'd just use i as normal, and the dot would be removed if you have an accent on it

this ain't great

[storm whale]

Isn't this the behaviour on main now tho

[grizzled granite]

isn't what the behavior?

[storm whale]

If you use hat(i) the dot is removed

[grizzled granite]

ah yes

and in fact it even works on other characters, like the double struck

TIL

so I guess typst is already doing this

[storm whale]

IIRC the implementation when I did it was a little janky because you can't really tell which variants the font supports

With the dtls feature

Like if you do hat(cal(i))

[grizzled granite]

the dtls feature is only for two characters no? soft_dotted seems more general

but I'm clueless

[grizzled granite]

that works in stix two math, but not in new computer modern math

[storm whale]

Reading that it seems that's just a list of the characters where you should remove the dot. I'm trying to figure out there how then you get the dotless glyph tho

[storm whale]

Yeah, newcm doesn't have script dotless

[grizzled granite]

aren't you already doing it? I'm confused

[grizzled granite]

you mean it's the list of characters that dtls affects?

theoretically if the font has support for it

[storm whale]

That's what I'm not sure about, as dtls is just for math layout, but the soft_dotted appears to have to do with accents in general, outside of math

I don't know how diacritics work exactly outside of math

[grizzled granite]

unicode and opentype fonts seem to be a lot more complicated than they really need to be...

[solemn scarab]

You are right. But as micro is a common case and typst supports aliases, an alias might be a good idea.

[solemn scarab]

I see. This would be a valid way to solve it

[grizzled granite]

I don't agree that adding micro is a good idea to be honest

that seems like the job of a package for units / SI prefixes

[midnight tangle]

Even for the separate micro sign?

[grizzled granite]

I think that's just normalized to a mu anyway

[midnight tangle]

It is not canonically equivalent to a mu (unlike the ohm sign, which is canonically equivalent to an Omega). However, it normalizes to a mu with the Normalization Form KD (NFKD), and the Normalization Form KC (NFKC), at least according to this site: https://dencode.com/en/string/unicode-normalization.

[solemn scarab]

And you got an ohm symbol!

[grizzled granite]

Which shouldn't be used

[midnight tangle]

We're removing it in the next version

[grizzled granite]

What does typst do?

[midnight tangle]

No idea, but I would expect it to not normalize anything

[grizzled granite]

It's weirdly inconsistent of unicode to not "deprecate" the micro symbol

[grizzled granite]

I think it does for some things

[midnight tangle]

Likely because "use of either character as a micro sign is common" (keyword: "common", not "recommended")

[grizzled granite]

Like, regular Greek letters are turned into the mathematical versions in math

[midnight tangle]

Oh ok

[midnight tangle]

This is different. I don't think it has anything to do with Unicode normalization

Normalization should keep the semantic. It just represents the same text in a different way (such as precomposing all accented letters or the opposite)

[grizzled granite]

I'd wager most uses of the micro symbol is just people hitting it on a keyboard thinking it's a regular mu

[midnight tangle]

Or reordering multiple adjacent combining diacritics

[midnight tangle]

Also most people don't care what a character is as long as it looks right

[grizzled granite]

But I do guess semantically it makes sense for screen readers and such to separate the two

[midnight tangle]

In French, some people use << and >> instead of « and » (in LaTeX this becomes the much lesser and much greater than symbols, which is terrible)

[grizzled granite]

But you could make the same argument for Ohm, which they deprecated

[midnight tangle]

The reason is that characters represent letters (except when they don't like emoji or Chinese characters), not meaning

[grizzled granite]

Ok but why is micro different?

It makes no sense to me

[midnight tangle]

But yes it is inconsistent, which is unavoidable at the scale of Unicode

[lapis moth]

someone said earlier that micro sign is reachable on some keyboards, which I can also confirm

[foggy folio]

If we’re talking about screenreaders then it kinda makes sense, micro is used to indicate size and is pretty common in that regard. You generally would want “μm” to be read as “micro-meters”, ohms instead are used as a separate measure so it’s more field-specific

[grizzled granite]

There's a variation selector for the empty set too apparently

[storm whale]

Yeah there's quite a few for some other math symbols, I am going to open an issue on codex about them

[midnight tangle]

I have implemented a way to deprecate symbols and modules in #19. Currently, Typst cannot make use of this information because it does not support deprecating constants, but I am working on a pull request to change that.

[storm whale]

I've opened a PR moving the implementation of these to Codex: https://github.com/typst/codex/pull/20

[midnight tangle]

Any opinions on what we should do with those symbols?

[storm whale]

I agree we should probably remove planck. And I think for the second one we should give the non italic variant a name instead, not sure what it should be though.

[midnight tangle]

For reference, unicode-math gives names to the italicized versions.
I think whether we name ℏ or ħ may also depends on what name we choose. For example, hbar could be ħ, but planck should probably be ℏ because ħ is just a Latin letter.

I think if we decide to name ħ hbar, it makes sense to also add Hbar for Ħ. (see https://en.wikipedia.org/wiki/H_with_stroke)

[grizzled granite]

Didn't you argue to keep other symbols for semantic reasons?

I don't recall which one(s) right now

[midnight tangle]

I don't recall anything like that. In this case $planck$ is exactly the same $h$, which is why I think we should remove the symbol.

[grizzled granite]

Oh I didn't realize it's literally the italic h

Y u be so weird unicode

[midnight tangle]

In this case it kinda makes sense: initially, only italic letters that were commonly used were added to Unicode. When they added all other italic letters, they did not add those that already existed, such as for h, which explains why the name is not just "mathematical italic small h".

[grizzled granite]

I know that it's important, but backwards compatibility makes me sad. It could be a lot simpler if they made a Unicode 2: Electric Bogaloo

It's historical baggage on top of historical baggage

Did you know the combining grapheme joiner does not join graphemes?

https://en.m.wikipedia.org/wiki/Combining_grapheme_joiner

[midnight tangle]

Unicode has a list of (known) anomalies: https://unicode.org/notes/tn27/

[lapis moth]

the issue with that is, of course, that Unicode isn't "done" (and will probably never be), so you'd just get new historical baggage from then on.

[grizzled granite]

New additions are largely new scripts

Or emojis

[lapis moth]

I think remove them both, and don't give ħ a name. Writing $ħ$ should already give you ℏ and giving it a name can be done in a package.

[midnight tangle]

I think ħ/ℏ is a commonly used symbol in physics.

[lapis moth]

It certainly is

[midnight tangle]

So it should be given a name

just like ell

[lapis moth]

Hmmm, okay fair I guess. My brain just doesn't seem to like the arbitraryness of "hey, this one letter with a decoration has a name, but not any of the other ones"

but, okay, then I'll vote for hbar for ℏ

[grizzled granite]

I'll just use the ħ key on my keyboard

[grizzled granite]

It's not just a letter with a decoration, it's a specific symbol

[midnight tangle]

ħ (the not italicized version) is used in the IPA (International Phonetic Alphabet) so it may make sense to name ħ instead

Although we have not given names to any IPA character for now I believe

[lapis moth]

Are we gonna name all the other IPA symbols as well then? (Not a gotcha question, this might actually make sense)

[grizzled granite]

Is the italic version actually the italicized version of the upright one though?

[heady fulcrum]

I'm not too familiar with physics, so I'm not sure I can contribute much other than to give my vote towards semantic names

[grizzled granite]

It seems coincidental that a similar symbol is used for ipa

[midnight tangle]

I don't really know. Not in the near future at least, but maybe at some point. Or maybe this is better left to packages

[heady fulcrum]

iirc, the planck constant is the h with the bar, right?

[grizzled granite]

Yes

[midnight tangle]

I believe so, and made a PR about that recently: https://github.com/typst/typst/pull/5492

[heady fulcrum]

If so, then I would vote for having that one be accessible (maybe through an alias) as planck

[lapis moth]

There's two planck constants. The "planck constant" is ℎ. The "reduced planck constant" is ℏ

[grizzled granite]

Yeah but no one use the full name

[heady fulcrum]

Ah, I see

[lapis moth]

with the definition ℏ = ℎ / (2pi)

[heady fulcrum]

if this is the common usage then why is the current planck and planck.reduced bad?

[midnight tangle]

If we go for a semantic name, I think planck is fine

[grizzled granite]

Because planck would just be a regular h

[heady fulcrum]

and that's a problem because?

[midnight tangle]

because people can just type "h"

[heady fulcrum]

well, alternatively we can just have a single planck and have that be the reduced one, no?

[grizzled granite]

And I'm fairly sure the reduced version is almost universally used anyway

[grizzled granite]

Yes

[midnight tangle]

This is one of the options indeed

[heady fulcrum]

since the other one is, as y'all are mentioning, just an h

[grizzled granite]

That's what they're proposing

[heady fulcrum]

Ah, got it

I understood from the proposal that planck was going to disappear 😅

[lapis moth]

Personally, I prefer symbol names that describe what it looks like, hence I'd like hbar more than planck (plus, it's shorter).

[heady fulcrum]

Then I think that's what I vote for

[lapis moth]

I'm still annoyed when I have to type (or redefine) and for the exterior product

[grizzled granite]

I prefer semantic names as long as its use is almost universal

But in this case I'd propose having both hbar and planck for the same symbol

[storm whale]

Is there an italic version of the capital H bar symbol?

[midnight tangle]

I don't think so

[grizzled granite]

There is a capital h bar?

[heady fulcrum]

I'm on board with this

[midnight tangle]

#1277628305142452306 message

[grizzled granite]

Ok, but that's exclusively an IPA symbol. If we start adding that then we should add all of them

[midnight tangle]

We could have:

• planck for ℏ
• hbar for ħ
• Hbar for Ħ

[storm whale]

Then I say we leave out the capital H bar for now

[grizzled granite]

You don't need a separate name for italic

They should both be for upright, which turn into italic in a math context

[midnight tangle]

No, the letter "h with stroke" (both cases) are used in Maltese according to https://en.wikipedia.org/wiki/H_with_stroke

[lapis moth]

if we go with this, It'd set a precedent for symbol aliasing, and then I'd also campaign for wedge/vee aliases for and/or

[grizzled granite]

Okay but my point still stands, since we don't have names for individual letters in other scripts

[storm whale]

I'm no physicist, but wouldn't it be weird if outside of a math context I did #sym.planck and got ħ instead of ℏ?

[grizzled granite]

There are symbol aliases for some symbols already

[midnight tangle]

Except planck specifically designates the planck constant, which is always italicized

[grizzled granite]

You shouldn't use syn.planck outside a math context

[lapis moth]

oh there are? Then I'll open an issue for what I said

[grizzled granite]

That doesn't mean we should have aliases for everything

[midnight tangle]

Well, they aren't relly aliases. Just duplicate symbols

[grizzled granite]

It's a maintenance chore, and should be reserved for special cases

[lapis moth]

same thing imo

[lapis moth]

which ones do we have currently then?

[midnight tangle]

No because they need to be maintained separately

[grizzled granite]

Is it though?

Some authors use upright symbols

[midnight tangle]

E.g., nothing and emptyset

[grizzled granite]

And it's just inconsistent

[midnight tangle]

Good point

[storm whale]

By giving it a semantic name though, a user should expect (rightly IMO) that it spits out the italic version outside of a math context

[grizzled granite]

Every other symbol corresponds to the upright version as far as I know

[grizzled granite]

I don't agree

That encourages using math symbols outside of a math context, which shouldn't be done

It'll be typeset in the wrong font for one

[midnight tangle]

not dotless.{i,j}

[storm whale]

it does now

i changed that semi recently

[midnight tangle]

since when?

oh great!

[storm whale]

when support for the dtls opentype feature was added

[midnight tangle]

Another argument in favor of adding the non-italicized version: upright(planck) would not work I think if it were the italicized version

[storm whale]

But I'd argue that it isn't necessarily a math symbol, which is supported by it being in the letterlike symbol block I guess.

[grizzled granite]

When is it used outside a math context?

Adding odd italic symbols seems like a mistake that'll have to be undone in some future version

And like I said, some authors definitely use the upright version.

[storm whale]

Yeah okay, fair enough. I guess a semantic alias isn't much harm anyways, given its widely used

[midnight tangle]

I created #24 (and corresponding Proposal 26), implementing the change we just discussed.

[lapis moth]

Here's a list of the current duplicates (as of 35c18a1):

sym duplicates:

• dot.double, diaer
• emptyset, nothing (all variants)
• nabla, gradient
• ast.op, convolve
• circle.stroked.tiny, compose
• infinity, oo
• eq.triple(.not), equiv(.not)
• plus.circle(.big), xor(.big)
• tack.b, top
• tack.t, bot

sym alternate spellings:

• alef, aleph
• bet, beth
• gimel, gimmel
• dalet, daleth

sym and emoji:

• sym.hash, emoji.hash
• sym.ast.basic, emoji.ast
• sym.copyright, emoji.copyright
• sym.trademark, emoji.tm
• sym.trademark.registered, emoji.reg
• sym.excl.{double, quest}, emoji.excl.{double, quest}
• sym.arrow.{l.r, t.b, tl, tr, bl, br, {l, r}.hook, {l, r, t, b}.filled, {t, b}.curve}, emoji.arrow.{l.r, t.b, tl, tr, bl, br, {l, r}.hook, {l, r, t, b}.filled, {t, b}.curve}
• sym.square.filled.big, emoji.square.black
• sym.square.filled.{tiny, small, medium}, emoji.square.black.{tiny, small, medium}
• sym.square.stroked.big, emoji.square.white
• sym.square.stroked.{tiny, small, medium}, emoji.square.white.{tiny, small, medium}
• sym.triangle.filled.{l, r}, emoji.triangle.{l, r}
• sym.ballot.check, emoji.ballot.check
• sym.suit.{spade, club, heart, diamond}.filled, emoji.suit.{spade, club, heart, diamond}
• sym.checkmark.heavy, emoji.checkmark.heavy
• sym.dash.wave.double, emoji.dash.wave.double

Not sure about that last group, maybe they're missing a variation selector or something?

Given that we have xor, I think adding wedge/vee for and/or should also be fine.

[grizzled granite]

Some of these can be disambiguated with a variation selector. Such as emptyset and nothing. Though few (if any) math fonts support that yet

[midnight tangle]

I'm surprised about the last group indeed. But the missing variation selectors is a known issue: https://github.com/typst/codex/issues/23 and https://github.com/typst/codex/issues/21

[lapis moth]

Should I open an issue with the whole list and then we can close those two?

[midnight tangle]

Yes I was thinking we could merge the two issues

Feel free to do that

[lapis moth]

Alright

https://github.com/typst/codex/issues/25

And I'll open one for wedge/vee as well. I think those are justified well enough.

[midnight tangle]

You can open a PR for that

That way, if the discussion decides that we should add them, we already have a PR

[lapis moth]

Ah, right, good thinking

https://github.com/typst/codex/pull/26

Maybe we also want to invest in a proper "alias" system, even tho we don't intend to use it that much.

[midnight tangle]

For reference, this was already proposed in typst/typst#4826 (comment)

I wouldn't create an alias system myself for now because it is easier to maintain some things in multiple places than to create an entire new system, but I agree that it might be useful long term.
As a side note, "alias" here is a very vague term. For example, if we add vee as an alternative for or, the alias should apply to all or.x.y.z variants, but also to, e.g., union.or.

Cursed idea 😈

wedge
  .t ∧
  .b ∨
  .l <
  .r >

[foggy folio]

I don’t know how’s the situation else where but in Italy in my math classes I’ve always referred to the and and or simbol with the Latin name “et” and “vel”, would be nice to also have that option

[grizzled granite]

That's literally just and and or in latin

[foggy folio]

Exactly

[grizzled granite]

I'm not sure I follow your reasoning

[foggy folio]

I don’t know, to me ∧ makes more sense associated with “et” instead of “and”

When thinking of “and” I think of the symbol &

[grizzled granite]

That's funny because & is literally a ligature of the word et

[foggy folio]

The more you know

That’s very cool

[heady fulcrum]

'and' is English, and thus will be more familiar to most users than 'et'

we're mainly thinking now of some name that is independent of the relation of this symbol to 'and', and so I don't think 'et' fits the bill for that purpose

at least IMO

[midnight tangle]

As a reminder, the following PRs are ready, and waiting for approvals from collaborators to be merged:

• Add gender symbols (Proposal 1) #2
• Add error bar symbols (Proposal 12) #10
• Add smaller than and larger than symbols (Proposal 11) #13
• Remove compatibility symbols (Proposal 19) #14
  Of course, we are in no rush so don't feel obligated to go review them if you don't have the time to (or simply don't want to). If you have issues with the PRs, feel free to voice them on GitHub or here.

[midnight tangle]

I just realized they actually responded to that! They just did not email me the answer (probably because it is still a draft). I posted an update on the original issue.

[grizzled granite]

We really should start documenting the default symbol class in the documentation,

And explain any deviations from the "official" document, or special behavior

[lapis moth]

Re Proposal 12: I'm not sure I like the name error. Feels to general, I think errorbar might be better. The unicode names also have the "bar" included

[heady fulcrum]

strong agree

I like errorbar. Way way better, it's very descriptive, and seems like it would fit in well in Typst code.

[midnight tangle]

For reference, this was very briefly discusses here: #1277628305142452306 message

So it's not like error was the result of many thoughts. In fact, I agree errorbar is better.

But there is also the alternative of, e.g., square.error

[lapis moth]

you mean your question and the singular reply? Or were there more replies further down?

[lapis moth]

Even then I'd prefer square.errorbar

[midnight tangle]

I meant my question and the singular reply

[lapis moth]

I don't really have a particular preference toward one order or the other btw, having errorbar first seems nice for grouping (since these symbols all look very similar), but the shape first makes slightly more sense semantically, since error bars are secondary to the actual data points.

[heady fulcrum]

I think I prefer starting with errorbar, makes much more sense group-wise. If I want a confidence interval / error bar symbol, I wouldn't think of going looking for it in square of all places.

[storm whale]

I was fine with just error because adding bar felt redundant with all of the modifiers: imo it is reasonably clear that error.square.stroked is an error bar. Though I don't mind errorbar either

[midnight tangle]

I changed error to errorbar in the PR

[lapis moth]

Another argument in favor of this are the unicode names, which are e.g. "error-barred square" and not "square with error bar". Your argument is also very good, so I think I'm convinced now

[lapis moth]

I'd expect a symbol just called error to be like ⚠ or 🛑

[lapis moth]

I'm in the process of implementing a simple alias system. Should oo also have the same variants as infinity? Currently it has none.

[midnight tangle]

I think it shouldn't

I feel like oo is conceptually more like a shorthand, and you can't do, e.g., ->.l

[lapis moth]

okay, fair. It simply won't be an alias then.

[river berry]

Should we change this to a shorthand? I feel like that does make more sense. However then it would be under Typst itself instead of Codex

[midnight tangle]

I don't think shorthands can contain letters

[river berry]

They can

[midnight tangle]

Interesting

Then idk

Does it change anything for the user?

[river berry]

They're just a specific series of characters. We would need to check that it doesn't split a word, but it shouldn't really have any affect on the user

[lapis moth]

Yeah let's do that then. It doesn't really make much sense as a symbol

[midnight tangle]

We would need to check that it doesn't split a word
Then I think it is probably better as a symbol. Especially if it does not change anything for the user (although symbols can be overridden, but shorthands cannot). Why reimplementing something that already works well?

[lapis moth]

sym.oo feels wrong

[midnight tangle]

That's not how it's meant to be used. sym.RR doesn't look good either imo

Also, symbols from sym are listed on https://typst.app/docs/reference/symbols/sym/

[lapis moth]

hm okay, good counterpoint.

[river berry]

but shorthands are also listed, e.g. Shorthand: -> for arrow

although you can't currently search by shorthands 🤷‍♂️

[midnight tangle]

I'll create a webapp issue for that

#521

[lapis moth]

Okay I've found a few more that'd gain variants with the simple alias system, namely

• xor would gain .arrow (from sym.plus)
• top and bot would gain .big, .double and .short (from tack.{t,b})

Would you say a more fine-grained approach to variants would be better?

(My current one just looks for a prefix)

[midnight tangle]

• xor.arrow feels like it should already be present.
• {top,bot}.{big,short} are okay imo.
• {top,bot}.double feel weird to me

My reason for not liking {top,bot}.double is that I see top and bot as up and down tacks, with specifically one bar. I see tack.double as an alternative to tack, not a more specific variant. The same way I don't see, e.g., plus as a rotated variant of times.

[river berry]

I think it feels weird to have top.double because top and bot are semantic names (for the top/bottom types in type theory) instead of display focused names. Similar to wedge vs. and. But I could see it being added just for user convenience and discoverability

There is no semantic meaning to "double" the bottom type

[midnight tangle]

Maybe we should consider top and bot not as alias of families of symbols, but as semantic names for specific characters

[lapis moth]

I want to weigh in on the implementation side here: Defining an alias as "all variants starting with tack.t" is very easy and makes it reflect all future changes to that. If we start adding exceptions, we'd have to maintain those manualy again

[river berry]

Could this be a useful categorization for symbols in general?

[river berry]

This is also very fair

[lapis moth]

Since top and bot currently have no variants, I could make a second single-variant type of alias, which would also make room for oo again.

[midnight tangle]

But what would be the point if they have no variant to maintain?

[lapis moth]

Also, I'm currently only doing symbol aliases, nothing with variants (those are a lot more complicated and hard to get right)

[river berry]

I think leaving it as two options, alias plus all variants or just alias, makes sense to me

[lapis moth]

deduplication 🤷

[lapis moth]

for example, an alias equiv to eq.triple would be perilous for tilde since we don't want tilde.eq.triple since modifiers are commutative (iiuc)

Or another one I found was angle.spheric.top, which shouldn't create angle.spheric.tack.b

[midnight tangle]

I think this is what you mean, but imo aliases should be for a specific symbol + some modifiers

[lapis moth]

please give an example, I'm not sure I understood this correctly

[midnight tangle]

The behavior should be the same as if the user created the following aliases themselves:

#let nothing = emptyset
#let xor = plus.circle

In this case, xor does not behave like a macro that is replaced with plus.circle when used in a symbol. It's just a name that's given to a symbol with pre-applied modifiers.

[lapis moth]

yep, that's how it works right now

And now I've also added support for single-variant aliases, which are arguably more "magic"

[midnight tangle]

Those would be like doing

#let top = symbol(tack.b)

[lapis moth]

I think I can also add support for arbitrary manually specified variant inheriting, but no existing symbol would make use of that, so maybe not.

i.e. #let top = symbol(tack.b, ("big", tack.b.big))

[midnight tangle]

This seems overkill just to avoid some repetition

[lapis moth]

Yeah and as I said, it wouldn't even be used right now

[lapis moth]

alright the pr is open: #27
cc @past python

@midnight tangle my alias syntax partly overlaps with your deprecation syntax in #19. I chose @ to define aliases since that symbol carries a sort of a "pointer" meaning. Maybe you could change the deprecation to start with # or ! instead?

(to be clear, this isn't a parser issue, no alias will be called deprecated:, but it's nicer to clearly distinguish different features)

[midnight tangle]

Maybe aliases could instead be

x = a.b.c
y.* = a.b.c

[lapis moth]

hm, I guess that would work, but it'd be a bit more effort to parse. (And also, I'd still want to keep the .* on the right side)

[midnight tangle]

Oh I thought the .* was meant to be on the left side in your PR, sorry.

I think modules use a similar syntax right now:

module_name {
...
}

[lapis moth]

Think of it as assigning a whole group of variants to y.

[midnight tangle]

I.e., the indication that it is a module comes after its name

[midnight tangle]

Yes this makes more sense indeed

[lapis moth]

hmmmmm, okay that's fair. But { doesn't conflict with a symbol.

With your proposed syntax, eq might be parsed as an alias if we're not careful

Maybe go the cursed shell-script way and make it

x= a.b.c

(no space after the x)

or, actually, it could just be :=

tho that doesn't feel right coming from typst

[midnight tangle]

We don't care about that. This is just some unimportant syntax to declare things more easily

I was gonna say we could just escape = when we need it as a synbol, but := is a better solution imo

[lapis moth]

hm, that would be slightly confusable with the value of colon.eq. Might not matter, but it's something to be said

okay, so how about @=

That keeps the @ to denote "alias" and the assignment for what it is

[midnight tangle]

Most people use fixed width fonts in this context, so this wouldn't be an issue

[midnight tangle]

why not

[grizzled granite]

Regarding top and bot

Could we verify that there aren't more symbols that have different class in LaTeX unicodemath than the official Unicode document?

[midnight tangle]

Yeah we should definitely do that. I may do it later today if I have the time

[lapis moth]

Given that they are operators, how about eq.op for ⩵ and eq.op.strict for ⩶? The latter being based on JavaScript's semantics.

[midnight tangle]

Typically, op modifiers correspond to a homoglyph with Binary math class

[lapis moth]

Another idea would be eq.two and eq.three. Though that's semantically the same as double and triple...

Next, something comment I'd like to add to Proposal 24 is a to alias for arrow.right. LaTeX has such an alias as well (\to is the same as \rightarrow) and if we use mapsto from LaTeX, we should have to as well imo.

Also, on a more meta-level, I dislike how the Proposal Document makes discussing things a bit annoying. I'd prefer to have a proper forum thread (i.e. GitHub issue) for each of the proposals, or at least for the more prominent ones.

For the subset and superset symbols with two equal strokes, I don't think .equiv is good at all. They're really variants of the regular su{b,p}set.eq and only ever used in that way (afaik). So I'd propose to call them .eq.alt instead

(tho the alt isn't ideal since modifiers are atomic and commutative)

LaTeX has is as \subseteqq

but .eqq is ugly and totally goes against our established conventions

[past python]

Btw, just to let you all know: I'm planning to cut a release of codex for Typst 0.13 fairly soon (in the next few days)

[lapis moth]

While I have you, can I replace the "Feature" labels on all codex issues (presumably kept when moving issues from typst) with the codex-native "enhancement"?

No, wait, "Feature" is a Type

wtf is the difference

Why do we have both

[past python]

It's a new GitHub feature

It just happened one day

[lapis moth]

Huh, so I suppose "enhancement" can go then?

[past python]

We don't use it on typst/typst so far, but @midnight tangle started using it in codex

[past python]

I guess. I'd leave the labelling up to you all.

[lapis moth]

@midnight tangle what do you think about the "enhancement" label? Do we still need it when we have the "Feature" type?

[past python]

Codex is a good place to experiment with the new GitHub stuff

[lapis moth]

true

[past python]

For typst/typst I need to be a bit surer before I replace all feature/bug labels with issue types

[midnight tangle]

Honestly I'm unsure it's even worth adding those symbols, especially knowing that they decompose to == and === (regular equal signs)

[midnight tangle]

I like that, but it seems less necessary given the user can just type -> anyway.
For mapsto arrows, you can also use the |-> shorthand, but it's annoying to type on some keyboards.

[lapis moth]

true, but I'd still want to to exist for consistency and to ease migration from LaTeX

[midnight tangle]

I agree this might be better now that we have a separate repo. We would have to think about the best way to organize discussions.

[lapis moth]

Maybe like this: One GH issue per proper proposal, but keep drafts more inofficial and discuss them here

[midnight tangle]

For reference, we already have, e.g., lt.equiv

[lapis moth]

Hm, I don't like that tbh. Maybe changing that too would be better

[midnight tangle]

Yes I think this makes sense, especially if we want to discuss proposals in arbitrary order like we are doing now (everything is kinda mixed up)

[lapis moth]

Mind if I go ahead and create all those issues now? (Excluding for those that already have PRs)

[midnight tangle]

I updated all codex issues to use types yesterday. I think types are organization-level

[midnight tangle]

I think something being an enhancement is orthogonal to it being a bug fix or a feature

[midnight tangle]

Would be great to merge the deprecation PR first, and the inter PR as well

[lapis moth]

Since you didn't say no, I'll just go and do that now. I think collecting the three "slant" proposals into a single issue would be good, right?

[midnight tangle]

Yeah some proposals are interconnected. Maybe only convert non-interconnected proposals to issues for now

[lapis moth]

Also for Proposal 5 (the power symbols) I'll just create a PR instead since it's so small. Where should those go in sym.txt?

[midnight tangle]

Honestly I was thinking we should remove this proposal instead of implementing it. It feels too arbitrary for now

But ofc this can be discussed in the PR if you decide to make one

[lapis moth]

Hm. You're right in that I don't see a use for them in written documents, but they're really universally recognized symbols, so I'd say adding them doesn't hurt.

[lapis moth]

(also I answered my own question already - they're miscellaneous technical symbols)

[past python]

yeah, I plan to take another look at the deprecation stuff before the release

and I approved inter

[lapis moth]

Just realized I didn't respond to this. Given that context, I'd say they're more of a curiosity and not a proper "symbol", so we should drop the proposal.

Tho we do have colon.double (∷)

Does that also decompose?

It apparently doesn't, lol

[lapis moth]

I'll add single issues for the ones that share a topic. I think that makes more sense, so they can be discussed in one shared context.

[lapis moth]

All done! Review away!

[midnight tangle]

This is more commonly used I think

[midnight tangle]

Thanks!

[lapis moth]

lmao

[heady fulcrum]

My email inbox sends their regards 😛

[midnight tangle]

Are you okay with me converting the images to actual text for accessibility, and to help moving away from the document for proposals?

[lapis moth]

Sure, I just didn't want to go through the effort of manually evaluating all the typst code.

[midnight tangle]

This would involve editing your comments, which is why I'm asking

[lapis moth]

I assume you won't just remove stuff

(or change what I said)

[midnight tangle]

No I just want to make the images actual text

But this is indeed annoying

I will also remove the proposals that were converted to issues from the document so that there is a single point of truth

[lapis moth]

So all of them😂

I didn't leave any out

(better to cross-check, but I went through them from top to bottom and don't think I missed any)

Actually, I did leave Proposal 6 out (the == stuff)

[midnight tangle]

In the future, I suggest we keep pull requests for finalized proposals, and use GitHub issues for discussions. That way, people can configure their notifications to PRs only, and still have a chance to give their opinion before actually merging a proposal, without being notified with every new message.

[midnight tangle]

I haven't yet taken the time to review the star symbols PR, but maybe we should have a shape submodule (under sym), which would contain stars, asterisks from Geometric Shapes Extended, and other shapes?

[austere kraken]

?r

$prec.eq$ vs. $prec.eq.not$

[austere kraken]

This is not intended, is it? (on the left the line is straight, on the right not)

[storm whale]

Could be font specific maybe?

[grizzled granite]

Wasn't this one of the things in one of the proposals?

Iirc

[midnight tangle]

Related: https://github.com/typst/codex/issues/37

[midnight tangle]

I just did that, and here are my results.
First of all, LaTeX does not have exactly the same math classes as Unicode. I did not match them one to one, but here are the LaTeX classes I considered to correspond to each Unicode class:

• No Unicode class: \mathord.
• Alphabetic: \mathalpha.
• Normal: \mathord, \mathover, and \mathunder.
• Diacritic: \mathaccent, \mathaccentwide, \mathbotaccent, \mathbotaccentwide, and \mathaccentoverlay.
• Glyph_Part: \mathord.
• Punctuation: \mathpunct.
• Opening: \mathopen.
• Closing: \mathclose.
• Fence: \mathfence.
• Large: \mathop.
• Relation (also contains arrows): \mathrel.
• Unary: none.
• Binary: \mathbin.
• Vary: \mathbin.
• Space: none.
• Special (X): none.
  The raw results are in the attached file. The format is TSV, with the values on each raw being the code point, the character, the LaTeX unicode-math math class, the Unicode math class (or "None" if Unicode associates no math class for this character), and what class I think we should use without thinking about it too much ("Either" means either the LaTeX class, or the Unicode class, "None" means no class, and "?" means I don't know).
  I also added some comments (lines starting with #).

[grizzled granite]

I will check it out later

Is the "one dot leader" symbol accessible in typst?

regarding your pr

[midnight tangle]

not right now. I added it as a draft to the Symbols document

[lapis moth]

@midnight tangle I think we should have a "proposal" label for issues. Do you agree?

[midnight tangle]

Yeah maybe

[lapis moth]

What would the label discription be?

I'm thinking of something like "This may still need discussion"

Well, I'll go with that for now. It can always be edited again if you have a better suggestion

[midnight tangle]

I just closed the outline dot leader PR, but right after doing that I realized it might still be correct to use this character. How do you interpret the following quote from the Unicode 16.0.0 Core Specification:

Leader Dots. Leader dots are typically seen in contexts such as a table of contents or in indices, where they represent a kind of style line, guiding the eye from an entry in the table to its associated page number. Usually leader dots are generated automatically by page formatting software and do not require the use of encoded characters. However, there are occasional plain text contexts in which a string of leader dots is represented as a sequence of characters. U+2024 ONE DOT LEADER and U+2025 TWO DOT LEADER are intended for such usage. U+2026 HORIZONTAL ELLIPSIS can also serve as a three-dot version of leader dots. These leader dot characters can be used to control, to a certain extent, the spacing of leader dots based on font design, in contexts where a simple sequence of full stops will not suffice.

I initially thought this was saying that dot leader characters should only be used in plain text scenarios, but reading this again, I now interpret it as "if the visual dots have to be characters, use those characters; otherwise, do not use characters"

[lapis moth]

Yeah, when you say it like that I have to agree

[midnight tangle]

More in depth results in #4985 (comment).

[midnight tangle]

I will post a comment about that under Laurenz's outline PR (I created mine hours before this one appeared, but now this small change is probably better suited there).

[midnight tangle]

Done: https://github.com/typst/typst/pull/5735#discussion_r1926055505

[lapis moth]

Yay for the deprecation feature getting merged! Now I could merge that into the Alias PR so they no longer conflict!

[past python]

I must admit that I'm a bit skeptical about the alias thing. It feels a bit like over-engineering to me. Do we expect to accumulate more aliases than the alias system has lines of code? In contrast to the copy-paste thing, aliases can just be handled by copy-paste after all.

[grizzled granite]

I think it's more about maintainability than lines of code

it's very easy to mess up copy pasting

[past python]

True but the alias system also needs to be maintained. And I think there was the whole question of aliases are just for symbols or also variants. Which is complication that copy paste does not suffer from.

[lapis moth]

A large chunk of that code is parsing/resolving modifiers, which could be cut if we get #30.

I'm certainly biased, but I don't think the current design is that bad.

Maybe an alternative would be something that automatically generates a list of duplicated, similar to my ad-hoc python code I used a while ago, but in the build.rs, so that any changes to duplicates get noticed

Tho that's not a robust thing either for keeping two copies of a symbol in sync

I just really think having e.g. emptyset and nothing have a duplicate of the whole list of variants isn't robust at all, it rather feels quite brittle.

[lapis moth]

Alright, I made a PR that addresses #30. Please consider it totally independent from this previous discussion; That just served as motivation. I did my best not to overengineer it this time.

[sullen skiff]

Is there more context about this decision, such as why degree.c only exists for compatibility?

[midnight tangle]

You should use °C (as two characters) instead. degree.c only exists for compatibility in Unicode because there is no need for it other than said compatibility

[hollow hamlet]

How about the Angstrom? I cannot use ° A to achieve this

[night crystal]

why the two character version is prefered btw? maybe i've missed something in this thread

[midnight tangle]

Non, but you can use whatever equivalent character Unicode recommends you use instead

[midnight tangle]

Because the precomposed form should not have been added in the first place. I don't know whether it was added for compatibility with another charset or by mistake though. Regardless, the character is now deprecated by Unicode (they can't actually remove it for backward compatibility reasons)

[midnight tangle]

Now that you say it it's true that we should have added a name for the replacement character before removing that one, because it is not easily accessible on a keyboard

This seems like a real issue

[meager hazel]

How can we type °C easily then without a unicode keyboard? Should it be $degree"C"$? Or custom symbol?

[midnight tangle]

Yes either that, or you have the ° sign on your keyboard

On my French AZERTY keyboard, I can write °

[sullen skiff]

We don't have that on our QWERT keyboard

[hollow hamlet]

Maybe #sym.degree;C in text? I am using US keyboard, and there is no such symbol.

[meager hazel]

And if $"C"$ were not fixed, it could be terrible to type $degree upright(C)$.

[midnight tangle]

Regarding Angstrom, it is a genuine mistake on my part not to have thought to add a replacement, and I will try to fix that before the next version of Typst is released.
For the other symbols, I did not know some keyboards did not have ° easily accessible.

[hollow hamlet]

On the other hand, I am wondering that, why not do the users a favor of keeping these commonly used symbols. We have some cost to input a ° symbol (at least I need to search on Google and copy one)

[midnight tangle]

The "right" solution is to stay in text mode and use that: #1277628305142452306 message

[hollow hamlet]

Otherwise, I need to let such symbols on every new document I compose

or import some package maybe

[sullen skiff]

Do we really expect to see packages that exist solely to revert Typst's new changes to symbols?

[midnight tangle]

You should not use the precomposed symbols. What you can do is

#let degreec = sym.degree + [C]

Even though ° is not easily accessible on some keyboards, I still believe removing degree.c and degree.f was the right decision, as they just shouldn't be used.
I think adding the above declaration to documents where you need it (or just using #sym.degree;C every time) is fine. This is similar to how you have to type, e.g., #sym.lambda;-calculus if you use a Latin keyboard

[hollow hamlet]

yes that is exactly what I mean in last reply. I need to add this line thousand times in my future documents. Then, is it possible to integrate this let command into the definitions of symbols (make it a built-in symbol to replace the current degree.c in <=0.12)?

[sullen skiff]

I also want to discuss this issue, can we have some built-in aliases for symbol combinations

since I don't really think let users define their symbols is a good idea

[midnight tangle]

For now, symbols must be single characters, so this is technically impossible. Even if we allow multi-character symbols in the future, we will probably keep them single glyphs. But this could be an exception if many people want it I guess (no promise though, especially because there has been no work toward multi-character symbols for now)

[midnight tangle]

Depending on the context, this might be better left to packages. Regardless, this would not be my decision in the end.

[night crystal]

oh, i didn't know it is deprecated. thx for explaination!

[hollow hamlet]

OK I see

Just one more tiny question, is the Angstrom symbol also deprecated in Unicode? cause I cannot come up with simple ways to make one Angstrom symbol (need to use place i guess?)

[sullen skiff]

even though it's deprecated in Unicode you can still use it

[midnight tangle]

you should use U+00C5 Å instead, which is a homoglyph

This is why the Angstrom symbol is deprecated, because this one should be used instead

This is explained here: https://www.unicode.org/versions/Unicode16.0.0/core-spec/chapter-22/#G20445

[hollow hamlet]

I see. thank you

Sorry I have a following up suggestion about this:
quoted from this PR https://github.com/typst/typst/pull/5326#issuecomment-2448090275:

Given that, as explained above, the character does not seem to be easily accessible on a Cyrillic keyboard, I agree we should add it to sym.
I am wondering if we could add the U+00C5 Å into sym ?

Because of the same reason that this symbol U+00C5 Å cannot be easily typed by US keyboards.

maybe in some name like sym.A.ring as the official name of this symbol is "Latin Capital Letter A with Ring Above"

[midnight tangle]

Yes, and as I wrote here #1277628305142452306 message ideally this would be done before Typst 0.13.0. I will work on that later today.

[hollow hamlet]

Great.

Merci

[midnight tangle]

@past python sorry for the ping.
I created typst/codex#47, which adds back sym.angstrom, except with the corresponding non-deprecated codepoint. As noted in the discussion above in this forge, some people used sym.angstrom and would have no way of easily inputting the symbol (either the deprecated one or the non-deprecated one) in the current state of things. Ideally, this should be merged (and a new version of Codex should be released) before Typst 0.13.0. I'm sorry for this oversight, especially with how long the PR was open and therefore how long I had to notice the issue.

[past python]

I'll include it

No worries about the ping btw. It's good that I'm not getting pinged all the time, but I feel like people are now getting scared to ping me 😅

[grizzled granite]

@midnight tangle this issue https://github.com/typst/typst/issues/5846 made me realize that we're missing shorthands for the low accents

they aren't mentioned in the proposals document either

Specifically U+331 and U+332

though there are possibly others also

[midnight tangle]

I did not know they existed. Feel free to open an issue

The document mainly contains mathematical symbols and symbols that belong to technical blocks (by which I mean blocks that aren't related to natural writing systems)

[grizzled granite]

U+332 is \mathunderbar in unicode-math

U+331 doesn't seem to have a shorthand in unicode-math, but it would be natural to include it

your proposals document makes my browser take up 9 GB memory btw @midnight tangle 😂

[midnight tangle]

Yeah it's pretty slow to compile, but I did not realize it took that much memory 😅

[grizzled granite]

it may be slightly less, I had other stuff open too

but it's at least like 4-5 GB

[midnight tangle]

I guess it can become a new benchmark, joining The Thesis

[midnight tangle]

Still unreasonably high

[grizzled granite]

What's the deal with this by the way?

?render ```
$
accent(x y,\u{332}) accent(x + y,\u{332})
$

[grizzled granite]

it renders higher with the plus

maybe something for @storm whale

[midnight tangle]

Yeah probably

[grizzled granite]

I'm guessing no one has been thinking about bottom accents :p

[midnight tangle]

?render ```
$
dash(x y) dash(x + y)
$

[midnight tangle]

It may be a font issue

[grizzled granite]

or typst is adding to the height for bottom accents instead of subtracting

it looks like it's adjusted up by the same amount the regular accent is

as in, a bug

@midnight tangle I made this issue https://github.com/typst/codex/issues/48

the list isn't exhaustive, since I had limited time

there are actually regular accents we're missing as well

[midnight tangle]

Thanks

[grizzled granite]

For some inexplicable reason NCMM has the one underdot and three underdot, but not two underdots

[storm whale]

AFAIK bottom accents aren't really supported in math fonts. There isn't the accent position information in the open type font spec

[grizzled granite]

I mean, these symbols are specifically intended for use in math

see e.g. the unicode-math picture above

and the math fonts do contain them

[storm whale]

Yeah but unlike in top accents there isn't information on positioning for bottom ones. In the picture above the triple underdot you can see looks kinda terrible in every font as it isn't centred

Luatex/xetex do something anyways to position it reasonably well. I forgot what exactly they're doing tho

[grizzled granite]

Surely it's possible to infer a decent position for them

[storm whale]

Yeah I think that's what *TeX are doing

[grizzled granite]

The vertical position of the underdash is strange though, it really does seem like it's being adjusted in the wrong direction

[storm whale]

We should be able to fix that, its assuming its a top accent in the code probably. Leading to that wack position

Should maybe reopn that issue specifically for fixing under accents 😅

[grizzled granite]

Which issue?

[storm whale]

The over/under accent one

Or just open a new one

[grizzled granite]

That was largely about the lack of shorthands

I already created a new one in the codex repository

[storm whale]

Ah fair enough

[grizzled granite]

positioning of accents is a separate issue

[storm whale]

That's what I meant (was trying to say, quite poorly), should open a new issue for that

[grizzled granite]

Do you know if there's a database which describes what symbols are used for?

In particular I'm confused about these

[storm whale]

There's the math class document from Unicode that gives some info on what they are used for

[grizzled granite]

you mean https://www.unicode.org/Public/math/revision-15/MathClass-15.txt ?

[storm whale]

Yeah

[grizzled granite]

that's just the math class, doesn't really help much

[storm whale]

Its something, at least aha

[grizzled granite]

true

[storm whale]

I think these might be not used in math as accents can grow in size

[grizzled granite]

the glyphs are present in stix two math at least

[storm whale]

Maybe its used in non math text?

[grizzled granite]

that would be stix two text

[storm whale]

They might just be ported over anyway to the math font?

[grizzled granite]

specifically, stix two math has 35c, 360, 361 and 362

[grizzled granite]

you might be right, they seem to be present in the text font too

[storm whale]

In creating a math font, I imagine you just clone the text font and work off that as the base, so there'll be glyphs that arent used (no idea if that's how it actually goes tho)

[grizzled granite]

I think some of these are for symbols that don't have stretchable versions though, like the underbreve and inverted breve

so there would be actual value in having them available

on the other hand, they're not present in mathclass15

but neither are the bottom harpoons and arrows, or double dot (though single and triple are..)

so I'm not sure how much that says

[storm whale]

Even with those tho a math font should probably have them as a variant for the non double symbol

[storm whale]

I imagine its just incomplete

[grizzled granite]

Yeah

Maybe another question for the Unicode consortium

[storm whale]

There should surely be bottom accent attachment info added to the opentpye font spec

[grizzled granite]

Yeah

[storm whale]

I've been wondering how one proposes stuff

[grizzled granite]

Pretty sure you would first need to become a member

[storm whale]

That sounds expensive

[grizzled granite]

Apparently there are individual memberships as low as $75 (or $35 for students), but they don't automatically grant access to technical committee meetings

[storm whale]

That's surprisingly reasonable

Do you have a link to this info

I'd be interested to investigate

[grizzled granite]

https://home.unicode.org/membership/membership-levels/

[storm whale]

Wait sorry I was taking more about the opentype spec

But ty anyways for sharing that

[grizzled granite]

Oh right

Which organization is responsible for that?

Iso?

[storm whale]

I'm not sure I think its Microsoft/adobe primarily? And then it ends up in iso later

I was struggling to find where discussion on the spec happens. Theres all this stuff about registering tags, but not so much on proposing things to existing ones, like MATH

[grizzled granite]

Yeah I don't know the answer to this

[storm whale]

I mentioned this a while ago as well, but I think pairwise kerning info also ought to be added to the MATH spec

That's one thing that was lost from the original cm fonts

[grizzled granite]

There's this repo, but it says it's just a placeholder

https://github.com/MicrosoftDocs/typography-issues

It does seem to be actively used though

There are some issues there specifically about making changes to the spec

[storm whale]

Ah. At face value it looks to be more about docs issue or general issue, not feature requests

[grizzled granite]

Maybe largely, but there is a "new technical proposal" label at least

In any case it might be your best bet to figure out if and how it is possible to contribute

[storm whale]

I'll open some issues later today

[midnight tangle]

The Unicode Core Spec tends to have some information about some symbols (not all of them though). Sections roughly correspond to blocks (on mobile, press "Contents" on the top right)

[past python]

for the compiler itself, it can be 4GB max because wasm32

the web app uses a bit on top of course

[short vigil]

Hello, I would like to see the directed angles symbol in typst, there's something similar in typst but it's not really right.

[midnight tangle]

I'm not sure what you man exactly by "directed angle"? Do you mean something like ∡ with an arrow on the arc? If so, I don't think such symbol exists in Unicode

Those are the angle symbols we know of that are missing a name in Typst

[short vigil]

Look I want a symbol like this, I believe that it is not available right now in typst

[grizzled granite]

?render #sym.angle.arc

[short vigil]

yeah I know that this exists, but the arc just extends out side of the angle symbol. It's just like those two symbols are not 100% the same

I wondered if there was a symbol that's better than this

[grizzled granite]

As far as I know there's no symbol in unicode that's specifically like what you have in your picture

Though some fonts may be closer

[short vigil]

Ok thank you for the information and your time

[grizzled granite]

@midnight tangle I'm too late I guess, but wouldn't something like power.toggle be better than power.on.off?

I know the unicode name is on-off, but still

[midnight tangle]

Mmm... this may be better indeed

Well, I guess you can create a pull request to change that and i would approve it

[grizzled granite]

There's no real hurry I guess

none of this will be in before 0.14 anyway

[midnight tangle]

Yes, but let's not forget about it either, it would be stupid for the current names to land in 0.14 and then make this a breaking change

[grizzled granite]

I'll create an issue at least

what about this https://www.compart.com/en/unicode/U+23FB by the way?

oh that's "standby"

that one is a bit weird too honestly

[midnight tangle]

Wait I thought it was standby you wanted to rename to toggle.

I think .toggle would be better than .standby, and .on.off is fine

[grizzled granite]

with the realization that the standby symbol exists, I agree

the standby symbol could also just be power

that would also make sense

unless that's taken by something else

[midnight tangle]

Just realized I have a thing that makes sure every character is present at most once in the document (to make sure there is no duplicate research work done). On my computer, it is responsible for 60 % of the compile time 😬

[midnight tangle]

It is also accessible through plain power

[grizzled granite]

you could make a flag that enables that feature

[midnight tangle]

Yeah I will do that

[grizzled granite]

oh right because it's the first entry?

but you could also just assign it to power and skip the standby name completely

just like angle is assigned to ∠

https://github.com/typst/codex/issues/49

[midnight tangle]

yes we could

[midnight tangle]

It made it sooo much faster to compile this is amazing. I no longer need to wait when scrolling through pages

[grizzled granite]

Speaking of that, we could consider whether this is the case for other existing symbols. As in, if there is a symbol that makes sense being at the top level.

[midnight tangle]

This sounds like something that would be very difficult to do but yeah we could do it. At least we should think about it for future symbols

[lapis moth]

I don't like that tbh, but if everyone else agrees then whatever

[grizzled granite]

Why?

[lapis moth]

Because I think of "power" as the group name for all these symbols and each modifier represents an action it can do to the power state.

(that's the best way I could put it to words)

[grizzled granite]

If someone asked for "the power symbol" what would they be looking for most likely?

I doubt anyone who hasn't read the ISO standard would have any clue that they call it the standby symbol specifically

it's also a word that many non-native english speakers wouldn't be familiar with

[midnight tangle]

with the information that was provided, the current state is probably ok. power does correspond to the right symbol, and power.standby is a name that corresponds more specifically to the symbol's definition

[grizzled granite]

anyway we don't have to make a decision now, it's going to be months before the next version

[midnight tangle]

Although it would only be listed as power.standby on the symbol list, not as power

[grizzled granite]

I feel uneasy relying on fallback, especially because it's not obvious from the symbol list what the actual order is

you would have to actively look at the code to find that out

[lapis moth]

hmm, okay, I'm willing to count that against this way of having it.

Tho that could also be fixed by making the docs better

[midnight tangle]

Now that I think about it, the fact that the symbol list does not always give the "best" name is actually a significant issue.

I will create a webapp issue for that, even though I'm not sure how this could be fixed (maybe by specifying a preferred name in Codex), because I feel like this is a real UX problem

(not sure if UX is the right term but you get my point)

[grizzled granite]

The problem is that especially if you start listing shortened names that are not top level then we're stuck with always adding symbols at the bottom unless we are willing to break backwards compatibility

I'm not convinced that allowing shortened names in the first place was a good idea

[storm whale]

I was wondering why the symbols doc took a surprisingly long time to compile aha

[grizzled granite]

personally I always use the full name

[midnight tangle]

Maybe not for all symbols, indeed. But it is useful sometimes

[grizzled granite]

useful sure, but it also has significant drawbacks

I don't want my documents silently switching out symbols because I relied on unstable names

[midnight tangle]

For the stars PR, I briefly took a look and it looked like most non-full names would work as desired (e.g., star.l for star.five.filled.stroked.l). But this is indeed something we should be careful about in the future

[grizzled granite]

if you want to keep the non-full names and also put them in the symbol list for each symbol (shortest name resolving to that symbol) then it should be made abundantly clear that stability is not guaranteed, which doesn't sound ideal to be honest

[midnight tangle]

Ok I have a potential solution (may be bad): each variant has two sets of modifiers Mmax and Mmin ⊆ Mmax. Mmax corresponds to the current modifiers, and Mmin would be a list of modifiers that would need to be present for the symbol to be valid. For example, having Mmin = Mmax would mean that all the modifiers need to be present. Currently, Mmin = ∅ for all variants.
That way, Mmin can be displayed on the symbol list as it would correspond to the minimal way of accessing the symbol.
But then I guess the question is: what is the point of Mmax? Why not always setting Mmax to Mmin?

[lapis moth]

#let rarrow = arrow.r.

That way you can never do rarrow.l (okay bad example) to get a left facing arrow, unlike if the right arrow were just arrow

(ignore the existence of arrow.l.r for this)

More explicitly: Mmax would be good for a clean tree structure, so that some things are on the same level instead of one of them arbitrarily being at the top

[lapis moth]

Also I have two things to say to this:

1. Strictly speaking, no symbol currently has guaranteed stability. Remember the 0. of the version.
2. Codex doesn't even currently define what a modifier is (cf. #46), that's all in typst for now. But I was also under the impression that typst considered these shortened names an explicit part of the API and just as stable as anything else for the symbols

[grizzled granite]

@past python may want to chime in

[midnight tangle]

The primary use-case of Codex is meant to be Typst for now, though (https://github.com/typst/codex/issues/5#issuecomment-2529659410)

[lapis moth]

Yes, but it's a separate crate for a reason, and that reason is, I believe, separation of concerns.

[midnight tangle]

One of the main reasons was also to let the development of symbol happen on a different pace, and in a more community-based maner

[lapis moth]

ah, okay, fair point.

[past python]

I'm not sure it really needs to be at the very bottom. I feel like the "compatible rule" is a bit more involved. But I may be wrong.

[midnight tangle]

I would like to bring back the discussion about {lt,gt}.eq.slant and {prec,succ}.curly.eq (#42).
It was previously suggested to replace .eq.slant with simply .seq (#1277628305142452306 message). The main drawback that was expressed was that "seq" reads like "sequence" (#1277628305142452306 message). As of right now, for people who prefer the slanted variant, it is not easy to insert at all. Using a shorter modifier would be beneficial to those users. The issue linked above contains more context.
If we chose to stay with the status quo, I suggest we consider changing the .slant modifier to .slanted (#43).

On an unrelated note, the gender symbols PR is waiting for approval (or disapproval).

[lapis moth]

I don't feel qualified to judge gender stuff🫥

[midnight tangle]

The names are pretty much taken straight from Unicode, but indeed it may be good to have someone make sure the names we chose are not problematic

[grizzled granite]

I like seq, but I feel like I've already made my case

[storm whale]

I personally prefer the look of the slanted variant, however, I use it through a show rule on the unslanted symbols. i.e.

#show sym.lt.eq: sym.lt.eq.slant
#show sym.gt.eq: sym.gt.eq.slant

That way I can still use the shorthands and lt.eq gt.eq. Even though the slanted variant has a separate codepoint, imo they are really just stylistic variants of each other (and I'd assume they aren't ever used together in math - could be wrong though). So I'd vote for the status quo, but with the change from .slant to .slanted for the modifier.

[midnight tangle]

If we chose to keep slanted versions as an additional modifier (i.e., .eq.slant or .eq.slanted), this begs the question of what we should do for prec and succ. The current prec.curly.eq and succ.curly.eq don't make much sense imo, especially if we assign symbols to bare .curly variants (see #36). Quoting #42:

Unicode defines the characters ⋞ EQUAL TO OR PRECEDES and ⋟ EQUAL TO OR SUCCEEDS, but no variant with a single horizontal line equal sign above ≺ or ≻. This may indicate that ≼ should be prec.eq, and ⪯ should be considered less common, and therefore use a more complex variant than plain eq (and similarly for ≽ and ⪰).

[grizzled granite]

I feel a sense of deja vu

I think my question last time was whether there was a non-curly slant version?

The symbols can just be prec.slant.eq and succ.slant.eq, if there's no need to disambiguate

Or eq.slant since it's supposed to modify eq

Though I still prefer prec.seq and succ.seq

[midnight tangle]

I'm sorry if I already asked those questions. It's frustrating that we can't reach a consensus. Ideally, there would be an alternative to .seq because I feel like "seq" reading like "sequence" is one of the major blockers.

[past python]

could someone give me an executive summary on the discussion?

[midnight tangle]

There is a summary in this issue https://github.com/typst/codex/issues/42

[grizzled granite]

Like, what would sequence even mean in the context of symbols?

I don't see this as an issue whatsoever

Plenty of abbreviations can technically be read as other things

Succ could be succulent

[midnight tangle]

I think most users would not understand what "seq" stands for here, and would remember it as a string of three arbitrary letters, rather than a meaningful abbreviation

[midnight tangle]

But in this context, users understand what it stands for

[grizzled granite]

We could easily add more context to the symbol list

The current names are clearly not ideal, and I've yet to see someone propose an actual alternative to seq that isn't awkward in some way

It would enable such nice symmetry as prec.seq and seq.prec, mirroring that of existing symbols like lt.eq and eq.lt

It's not like it's completely obvious that lt means "less than" either

[lapis moth]

has someone suggested sleq already?

[grizzled granite]

That has leq in it

[midnight tangle]

This is yet another proposal. What would be seq alone, then?

[grizzled granite]

I just assumed that was part of the proposal since the symbols existed

[midnight tangle]

Oh right, you mean the inverted prec symbol

[grizzled granite]

seq alone wouldn't be anything, but seq.prec and seq.succ are obvious symbols

[grizzled granite]

I mean the ones where the slanted line goes on top

[grizzled granite]

If they're not already in the proposal I suggest adding them

[past python]

In my opinion it's important to differentiate between .neq and .eq.not because both make sense. With seq and eq.slant that's less so because gt.slant alone doesn't really make sense because gt is always slanted. The slant necessarily applies to the eq part.

I can see how it would perhaps be technically more consistent, but practically I think restricting ourselves in a way that no modifier shall modify the appearance of symbol pieces created by another modifier is not really helpful

[grizzled granite]

An important point here is that a pretty significant number of people want to always use the slanted equal. By choosing a shorter name we enable them to use the symbol without forcing them to create shorthands

[past python]

what about the show rule solution?

#1277628305142452306 message

[grizzled granite]

I'm of the opinion that show rules shouldn't be necessary here. Having a less cumbersome name in the first place is better.

These symbols are ones where many of those using them will use them a lot. Having a long name for symbols that are only used occasionally is more acceptable

[midnight tangle]

Unicode defines struck and double-struck variants for multiple arrows (such as ⇸ and ⇻). For the singly struck arrows, I think the .struck modifier is good. Do you have an idea for doubly struck variants? Maybe .doublestruck, or .dstruck?
Additionally, do you prefer .x or .cross (or maybe something else) for ⥇ (an arrow going through an X-shaped cross)?

[midnight tangle]

I created #50.

[lapis moth]

I wonder if there's a hybrid way for modifiers to work with some modifiers being commutative and some being non-commutative. @past python would you in principle be willing to consider such a system?

One idea for such a system would be arrow.double.struck (⤃) being different from arrow.struck.double (which would be ⇻), i.e. double would be a non-commutative modifier. (Example symbol from #50, since that's such a good example)

[midnight tangle]

I don't think this would be a good idea. It would make the system more complex, and in this case this can be fixed by just finding a good name for the double struck modifier

[lapis moth]

We already have "modifiers modifying modifiers" tho, e.g. eq.dots.down, where eq.down makes no sense. If we're aiming for consistency, and I strongly believe we should, this should then really be eq.downdots or something of the sort.

[midnight tangle]

With my proposal, eq.down without the dots modifier could be made invalid

But I agree that in general symbol naming can't be perfect, and there are many inconsistencies. I think would should aim for the simplest system: modifiers constitute a set (my proposal already deviates a bit from that, imo for the better) and try to work with it to make each individual variant feel logical, and as guessable as possible, beyond the inevitable inconsistencies.

[lapis moth]

Hmmm, your proposal is almost already one level of non-commutativity. In fact, I think it'd make more sense for (using the same example) eq.down.dots to be invalid, instead requiring eq.dots.down because .dots is in the Mmin of .dots.down and .down isn't.

@midnight tangle thoughts?

[midnight tangle]

.down would be in the Mmin, because eq.dots is a separate symbol.

eq.down.dots is indeed suboptimal, but it's fine in terms of breakage, which is what my proposal is trying to solve

[lapis moth]

ah, my bad then.

[midnight tangle]

integral.sect is listed as deprecated on the General Symbols list, even though it is not actually deprecated in the codebase (for technical reasons). Great job!

[midnight tangle]

https://github.com/typst/codex/issues/51

Honestly the more I think about it the more I like this idea

[midnight tangle]

Re: #contributors message
Aliases are a different thing (which does not exist as of right now). I don't think we should use them in this way.
There are many cases where it makes sense to rely on a fallback, and defining all those cases with aliases would be more complicated than the proposed ? syntax in the issue's comments.

[tall quail]

It doesn't have to be more complicated... My proposal would be that we write arrow.bar.r? to define the symbol arrow.bar.r and at the same time the alias arrow.bar. This has two benefits:

1. As I understand you would allow having both arrow.bar.l? and arrow.bar.r? , so the backward compatibility problem remains (or did I miss something?).
   With the alias concept, arrow.bar.r? defines arrow.bar and there cannot be another symbol added later with the same modifier set.
2. With aliases, if you see the code arrow.bar and the symbol definition arrow.bar.r?, you know that the code corresponds to this symbol. With your proposal (as I understand), you still don't know what the code does: you would have to check for other symbols (that could match arrow.bar) to be sure, and know which one takes precedence

but maybe I misunderstood the proposal

(maybe my use of "alias" is confusing if it already means something else, but we can find another word if necessary)

[midnight tangle]

1. Although I did not explicitely mention that defining both arrow.bar.l? and arrow.bar.r? would be legal, I recognize this is an issue I did not think of. However, we can have some form of automated system to detect this kind of issue.
2. This can be solved the same.

[midnight tangle]

I think you use it in the same way we do

In the end, I feel like both your suggesting and my proposal achieve the same result and could be implemented using similar syntax. Whether the underlying behavior is the creation of aliases or the two sets I presented is probably an implementation detail more than I realized.

I'm not sure if what I just wrote is very clear

One advantage of my proposal is that it makes it clear what is the fully qualified form, and what is the minimal name, which wouldn't be as easy with a bunch of unrelated aliases

[lapis moth]

well I'd disagree a bit

these are two slightly different conceptions of how modifiers work, fundamentally

the alias approach would mean we rip out the shorthand stuff from the variant resolving algorithm

while the two-set approach would mean we add more data to symbols and incorporate that into the algorithm

this is definitely observable, so I wouldn't call it an implementation detail, even if the two are in effect very similar

[lapis moth]

also I think this makes your approach the clear favorite

[midnight tangle]

How would it be observable?

[lapis moth]

First of all at the API boundary between codex and typst, tho you probably don't care much about that. Secondly the symbol list would probably look different, tho maybe it could pave over the alias approach and make it look more coherent than unrelated variants.

Maybe "definitely" was too strong of a word choice ig

But we also have to think about how/if this would interact with user-defined symbols in typst

[midnight tangle]

Secondly the symbol list would probably look different
That's fair

[midnight tangle]

We can either allow the ? syntax (or similar) in Typst when defining symbols (probably very easy to do).

If we allow the ? syntax, old symbols would break because they would need to have ? on every modifier to work like before

[midnight tangle]

Regarding the API boundary, with this potential improvement to variant selection fallbacks, I have become convinced variant selection should definitely be part of Codex.

[lapis moth]

that approach would also lend itself to the ModifierSet type like I've implemented it in #46.

[lapis moth]

yay!🥳

[midnight tangle]

I still haven't taken a look at the content of the PR though

Since I wasn't convinced by it a few days ago, I did not want to review it until I was sure we would decide to add it

[lapis moth]

No pressure, tho I think that one should def be merged before the other change we just discussed

[tall quail]

what is the role of shorthands in the resolving algorithm?

[tall quail]

If we add to your proposal that it's forbidden to have two symbols with the same minimal set, then I agree our two ideas are essentially equivalent

though I think the concept of aliases is easier to grasp than the description with minimal sets

[tall quail]

The symbol list should not show all aliases are independent symbols: there should be only one entry, for example arrow.bar.r? which shows to the user that arrow.bar is also a valid way to input this symbol

(by "aliases" I just mean different ways of specifying the same symbol, not a duplication of symbols)

I guess the difference is that I Iook at it from the user point of you and you from the implementer point of view 🙂

[midnight tangle]

I think they meant shorthand as in non-full qualified forms with fallback

[tall quail]

ah that makes sense. Then I would say:

[tall quail]

probably the implementation would still do something similar: there's only one symbol with several (shorter) aliases, and there would still be an algorithm to check if a short form matches this or that symbol

Ah there's another difference between our proposals: with aliases, it's clear that there can be only one match for a given set of modifiers. No need to "choose the first match". This way the backward compatibility problem is really fixed.

A hypothetical symbol arrow.r?.bar.short? would define arrow.r.bar.short with aliases arrow.r.bar, arrow.bar.short and arrow.bar. (These are not to be matched as strings, but as sets of modifiers so we still have commutativity)

By the way I would love to see some good examples of optional modifiers other than r... It would be helpful for thinking this through

[midnight tangle]

For example, .standby in power.standby, .six in die.six

[tall quail]

looks like it would be rare to have more than one optional modifier in the same symbol right?

[midnight tangle]

Not necessarily

Another example: errorbar for errorbar.square.stroked

[tall quail]

I think most people will want to use <= and >= shorthands rather than lt.eq and gt.eq. The show rule solution is best in this sense.

Though it's maybe not ideal that the show rule works on symbols: you cannot easily get lt.eq when you have #show sym.lt.eq: sym.lt.eq.slant.

It would be nice to have shorthand elements as target of show rules: by default shorthand.lt-eq would resolve to lt.eq but this could be changed with a show rule, without affecting code that specifies sym.lt.eq explicitly

[midnight tangle]

This is a good point: it may be better to add the ability to override shorthands, than to change the name of a symbol just because people won't be able to use the corresponding shorthand

And I like the idea of shorthands creating elements whose appearance can be modified with a show rule

That way, you could also have templates that, e.g., change the appearance of <= to be slanted according to the language or region

[past python]

I think a normal text show rule is the way to go here honestly

The downside that you can't get the other symbol another can be solved with revoke rules down the road

[tall quail]

I liked the idea of making shorthands a "layer" that users can configure to their liking without affecting symbols that are written without shorthands...

but maybe it's not worth the complication

[lapis moth]

we should probably have to add a compile time check that no shorthands overlap anyway. The question would then just be how this integrates with custom symbols: typst would probably have to duplicate that check somehow, or maybe it could go on ModifierSet in some way.

[tall quail]

right, but then this constraint should be part of the spec

I'll try to come up with a clean version of my proposal and put it as a comment on https://github.com/typst/codex/issues/51

[midnight tangle]

The struck arrows PR is now ready for review: https://github.com/typst/codex/pull/50

[rough light]

it seems đ is missing: #quick-questions message

[grizzled granite]

It's not a math symbol and doesn't have a shorthand in unicode-math, so that's probably why

but definitely should be added

[lapis moth]

@midnight tangle Re: #24 (comment): What "precise warnings" do you mean? From what you described earlier, it could just be done with regular deprecation messages, could it not?

[past python]

the deprecation system only supports deprecating a full symbol, not a variant

[lapis moth]

ahh, I should've known

[storm whale]

Re: https://github.com/typst/typst/issues/5922. Is there actually an issue with the variation selector in shaping? It looks as though it was fixed in https://github.com/typst/typst/issues/2448. This seems more like an issue for Codex

[midnight tangle]

Honnestly I'm kinda lost. But indeed there will be similar issues until Codex supports multi-character symbols

[past python]

I'm lost too

[storm whale]

That makes three of us 😅

[midnight tangle]

@past python regarding sym.planck, do you think the smooth path should be taken?

[past python]

honestly I don't care too much, I'm a bit tired of all the careful stepping around even though we're in 0.x

[grizzled granite]

move fast and break things 🔨

[lapis moth]

Then I'll drop my concern and say we can just do it in one go.

[lapis moth]

Tho you're probably the one who'll have to close the influx of "planck suddenly changed" issues...

[midnight tangle]

#46 is now ready to be merged for me. If you have the time, please go review the PR.

[valid marten]

like torvards/linux does, some PRs to subsystems could be split, reviewed, and merged just once before released, e.g. codex. Not sure whether it fits typst's development style.

[vapid osprey]

isn't this more of a font selection issue? in his 🗑 example on github, the emoji variant uses "SegoeUI Emoji" while the symbolic variant uses "SegoeUI Symbol" (on windows that is). Both of these fonts probably only support one variant ignoring any variation selectors

[subtle cypress]

Hi, not sure if this was mentioned before, but what are your thoughts on allowing the not modifier to be specified first? For example, in.not would equal not.in. I'm in favor of this since it reads more naturally.

[midnight tangle]

The issue with this idea is that what comes before the first period is not a modifier, it's the base symbol name.
Conceptually, x.y.z is the symbol x with features y and z. For example, arrow.r.double is an arrow, pointing to the right, and with a double line. It makes sense to allow writing arrow.double.r instead. However, double.arrow.r would be a "double" with an arrow and oriented to the right.
Similarly, not corresponds to the negation symbol used in logic (¬). With this in mind, not.in would be this symbol above the "element of" symbol (∈), or something like that.

[subtle cypress]

Ah, I see. There is no way for me to individually override this behavior right? Currently I have notin (without the period) defined as in.not, but there is no way to accomplish this with the period right?

[grizzled granite]

You can override not with your own symbol

https://typst.app/docs/reference/foundations/symbol/

See the constructor here

[subtle cypress]

Thank you!!

[storm whale]

Sorry if I'm a bit confused, but do you mean that in Typst they're maybe using two separate fonts and so nothing happens with the variation selectors (as they are not involved in the fallback at all?)

[vapid osprey]

Not that they're using two separate fonts, but that they're both using the same font in Typst. When both variants fall back to e.g. Noto Color Emoji, then we'll never get a non-colored emoji as the font doesn't have them regardless of the variation selector. We'd need to use e.g. Noto Emoji instead and probably handle the font selection/fallback based on the variation selector.

[midnight tangle]

@vapid osprey another issue to report to the NewCM maintainers: U+2985 LEFT WHITE PARENTHESIS and U+27EC MATHEMATICAL LEFT WHITE TORTOISE SHELL BRACKET use the same glyphs, and similarly for their right counterparts. Here is a screenshot from the General Symbols page. If the glyphs are different, they are way too similar to be used differently in math.

[grizzled granite]

Have you verified this outside the symbol page?

The symbol page uses fallback, which means it can be weird sometimes

[midnight tangle]

Yes I verified it in the webapp

[rough light]

@grizzled granite perhaps something to fix with the markup mode diaereses

?r #sym.diaer("i")

[grizzled granite]

Yeah I discovered that, but the accent functions are largely intended for math

[rough light]

true enough

[grizzled granite]

there's already an open issue

https://github.com/typst/typst/issues/833

I lean towards this being the job of the code editor

though there probably should be a way eventually

[midnight tangle]

I rend to agree with that. If you need a specific accent in your language, it is likely easily accessible on your keyboard, and if you often write the name of a foreign person that has an accent in it, you can just use a show rule.

[grizzled granite]

I still think it should be possible eventually, even if not particularly ergonomic or encouraged

[midnight tangle]

A friend of mine opened this PR that adds open-headed arrows: https://github.com/typst/codex/pull/54

[lapis moth]

https://github.com/typst/codex/pull/46

[midnight tangle]

I created a PR to deprecate sym.diff (with explanation in the PR description): #55.

[midnight tangle]

Regarding this PR, we probably shoudn't merge it without Laurenz's approval anyway, so I don't think we need someone else to review it (of course, if you have the time, feel free to leave feedback).

[grizzled granite]

Regarding the issue that was opened recently

If we want something for dif closer to how its pronounced then dee is a possibility. That's in fact how I've seen it named in some latex macros