Backward implication and less-than-or-equal <= ligature conflict

[chtenb]

This screenshot illustrates how sometimes the character sequence <= should not be rendered as above, but rather as a backward implication arrow. The example shows an class definition in PureScript, but I'm sure this occurs in other situations as well.

Proposed technical implementation details

I'm not sure how to solve this in a decent way. Perhaps some feature flag which enables an alternate set of ligatures?

[aaronbell]

Hm. I could add a stylistic set that would disable these mathematical versions, but it would disable them everywhere and make it so that they look the same as the arrows versions, which I don’t think is ideal.

Do you think it would be possible to establish a set of purescript-specific special cases where we disable that math instance?

Like: “<= Monad” then disable.

[aaronbell]

Alternatively, just use Cascadia Mono which has all ligatures disabled!

[chtenb]

Do you think it would be possible to establish a set of purescript-specific special cases where we disable that math instance?

I don't think so. The backwards arrow can be surround by pretty much any string of alphanumeric characters.

Alternatively, just use Cascadia Mono which has all ligatures disabled!

Yes that I could, but I really like ligatures :D

Hm. I could add a stylistic set that would disable these mathematical versions, but it would disable them everywhere and make it so that they look the same as the arrows versions, which I don’t think is ideal.

I'm not sure I understand this. But ideally in PureScript this sequence should be rendered as a backward implication arrow ligature. How feasible is it to release language-specific versions of Cascadia Code?

[aaronbell]

I'm not sure I understand this. But ideally in PureScript this sequence should be rendered as a backward implication arrow ligature.

Basically, it means that the mathematical version of the ligature would be disabled everywhere, even in cases where it would make sense to use it, such as if m <= 0. Maybe given the situation for purescript, though, it makes sense to do so.

How feasible is it to release language-specific versions of Cascadia Code?

It isn't :)

[chtenb]

It isn't :)

What about different ligaturesets or font versions for applications broader than a single language?

[chtenb]

Related issue: https://github.com/microsoft/cascadia-code/issues/435

[aaronbell]

I do not intend to cut two different versions of the font with a separate set of ligatures. The most viable option is to add a stylistic set that disables the mathematical variants so that you can have arrows instead.

[chtenb]

Something like that sounds reasonable. What exactly constitutes the set of "mathematical variants" that would be disabled?

[aaronbell]

I think the two would be <= and >=. I may also redesign the ligatures for <<=, =<<, >>= and =>>.

[chtenb]

So that would mean that whenever this set is enabled all those operators will render as arrow-like shapes? That sounds like a good solution that would cover a lot of cases, not just the PureScript case.

[aaronbell]

Yup! The problem is that they’re not particularly recognizable as math symbols. So give and take :)

[chtenb]

Cool. How would one normally enable or disable such a stylistic set?

[aaronbell]

It depends on the application. For example, here's how in visual studio code. So you'd need to look up how to do it in your specific editor of choice.

[chtenb]

I use VSCode, so there is that 😄

[chtenb]

Would it be possible to put the <= and >= into their own stylistic set? I think these are the only ones that are subject to ambiguity at the moment. The other arrow like ligatures could then stay enabled.

[Roshinator]

I think putting it in its own stylistic set would still be useful on its own since applications like windows terminal could take advantage of it. Compare-Object in powershell is one example where a double arrow left would be nice to have. I believe fira code has a stylistic set for this as well.

[jessiewestlake]

I think putting it in its own stylistic set would still be useful on its own since applications like windows terminal could take advantage of it. Compare-Object in powershell is one example where a double arrow left would be nice to have. I believe fira code has a stylistic set for this as well.

I came here to say the same thing.

The current implementation results in this with PowerShell in Windows Terminal:

I think the easiest solution would be for the PowerShell team to change their side indicators from using equals to using dashes, but that could break a lot of backward compatibility of scripts and things.

It's easier to distinguish the direction of the single lines than the double lines (in this picture I edited the left arrows to be the correct length).