You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
More granular options to ss01 and alternatives for (== and != and === and !==) #375
The ss01 option includes these ligatures seemingly inspired by Fira Code's liga:
== becomes a wide equal sign with no visible gap
!= adds a slash across this ==
=== becomes a stack of three dashes
!== adds a slash across this ===
I was never fond of this, as it makes = and == less distinguishable and obfuscates the meaning of ===. Thankfully, Fira Code offers an alternative via ss08:
== merges somewhat but retains a small gap
!= adds a slash across this == but the gap remains noticeable
=== merges somewhat but retains small gaps
!== adds a slash across the middle = of this ===
It would be nice if these were also available in Monaspace.
That said, this draws attention to a bigger issue: ss01 includes many unrelated ligatures that you wouldn't want enabled in all contexts. For instance, the substitutions for !~, ~~, =~ and ~~ would make no sense in languages where ~ is the binary inverse operator, yet you can't leave them out if you want to enable the substitutions for != and !==.
I personally am not so much of a fan of the 4 programming ligatures you mentioned.
* `==` becomes a wide equal sign with no visible gap
* `!=` adds a slash across this `==`
* `===` becomes a stack of three dashes
* `!==` adds a slash across this `===`
Thus, I support the proposal for the alternative ligatures to those.
I also support this proposal. I highly recommend looking at the approach taken by 0xProto(attached below); Their ligatures preserve small gaps so individual characters don't completely lose their original form. Personally, I'd love to see this style applied across the board, especially for arrow ligatures.
That's an interesting compromise. But in hindsight, I think giving fonts more granular options for such ligatures is mostly a hack, and so is making more conservative substitutions.
These code ligatures still rely on assumptions about syntax, and our code editors aren't yet smart enough to only apply them in the right contexts, so we end up with nonsensical ligatures across tokens or within literals. I've had to give up on Fira Code because even its options weren't enough to prevent nonsensical ligatures from rendering in regular expressions, so I've come back to Monaspace Neon with only its liga option enabled for texture healing.
I still think more granular options would be better than what Monaspace's ss01 does at the moment, but at this point I think I'd stick to just liga anyways, for reliability.
Activity
jothefiredragon commentedon Apr 3, 2026
I personally am not so much of a fan of the 4 programming ligatures you mentioned.
Thus, I support the proposal for the alternative ligatures to those.
spacekobie commentedon Jul 18, 2026
I also support this proposal. I highly recommend looking at the approach taken by 0xProto(attached below); Their ligatures preserve small gaps so individual characters don't completely lose their original form. Personally, I'd love to see this style applied across the board, especially for arrow ligatures.
DominoPivot commentedon Jul 18, 2026
That's an interesting compromise. But in hindsight, I think giving fonts more granular options for such ligatures is mostly a hack, and so is making more conservative substitutions.
These code ligatures still rely on assumptions about syntax, and our code editors aren't yet smart enough to only apply them in the right contexts, so we end up with nonsensical ligatures across tokens or within literals. I've had to give up on Fira Code because even its options weren't enough to prevent nonsensical ligatures from rendering in regular expressions, so I've come back to Monaspace Neon with only its
ligaoption enabled for texture healing.I still think more granular options would be better than what Monaspace's
ss01does at the moment, but at this point I think I'd stick to justligaanyways, for reliability.