Skip to content

More granular options to ss01 and alternatives for (== and != and === and !==) #375

Open

Description

@DominoPivot

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

Activity

  1. jothefiredragon commented on Apr 3, 2026

    @jothefiredragon

    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.

  2. spacekobie commented on Jul 18, 2026

    @spacekobie

    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.

    Image
  3. DominoPivot commented on Jul 18, 2026

    @DominoPivot
    Author

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions