Ligature issues when using `<`/`>` for generics

[matthew-e-brown]

The <> characters are commonly used like brackets in languages with generics. Unfortunately, that leads to some places where their existing ligatures cause problems:

Issue 1: >:

When the >: characters appear together, but are meant to have different highlighting, the ligature breaks things and ends up looking very odd. For example, in this code:

pub trait Action<S>: Clone
where
    S: State,
{
    // ...
}

The : should appear in red, and the < > should be in white/gray. However, the >: appear as one glyph and so they are both rendered in red:

You can see that also the > is pulled away from the S a little bit, making the spacing asymmetric (similar to the next issue).

Issue 2: >>>

When a generic type gets complicated, it's not uncommon to have multiple closing-angle-brackets in a row, like: >>>. However, because this >>> is a ligature, the spacing gets a little awkward as the three brackets are spaced away from the text beside them:

This does also happen with >>, but the spacing is much smaller and so it is not really noticeable without zooming in.

I don't have any examples on hand, but I suspect this is probably an issue with <<< as well.

---

Since these >>> and >: are valid ligatures, and they make sense to use for operators or similar, I don't think they should be removed or anything like that. I suspect, rather than trying to tweak these existing ligatures to work well in these edge-cases, simply having a feature flag / cvXX to disable them when working in generic-heavy languages like Rust would be a fairly decent approach. That way you don't need to try and account for all the bizarre ways these characters may be used.

Although, there are a lot of feature flags already... I feel bad asking for another one. 😅

[subframe7536]

Your request is quite fair, totally agree.

And I am just rethinking of ligatures. I will write some thoughts in discussion later this week

[Gn3po4g]

kind of like the >> conflict with right shift that occurred in c++ before.

[subframe7536]

in #240

[subframe7536]

In v7.0-beta28, by default, << / <<< should have tailing space, >> / >>> should have heading space. You can use ss07 to bypass this rule.

[vinzlee97]

In v7.0-beta28, by default, << / <<< should have tailing space, >> / >>> should have heading space. You can use ss07 to bypass this rule.

I noticed that by default multiple < and multiple > doesn't have a heading/trailing space until I enabled ss07, cmiiw.

[subframe7536]

In v7.0-beta28, by default, << / <<< should have tailing space, >> / >>> should have heading space. You can use ss07 to bypass this rule.

I noticed that by default multiple < and multiple > doesn't have a heading/trailing space until I enabled ss07, cmiiw.

Detailed explaination:

• By default: use << / <<< / >> / >>> instead of << / <<< / >> / >>> to show the ligatures
• Enable ss07: << / <<< / >> / >>> will also show the ligatures

[Gn3po4g]

I think ss07: Make space optional in multiple less or greater and ignore in config.json are not explicit enough. Can config.json use explicit enable and disable options?

[vinzlee97]

In v7.0-beta28, by default, << / <<< should have tailing space, >> / >>> should have heading space. You can use ss07 to bypass this rule.

I noticed that by default multiple < and multiple > doesn't have a heading/trailing space until I enabled ss07, cmiiw.

Detailed explaination:

• By default: use << / <<< / >> / >>> instead of << / <<< / >> / >>> to show the ligatures

• Enable ss07: << / <<< / >> / >>> will also show the ligatures

I can't see any of these ligatures when I set ss07 to default ignore settings.

I think ss07: Make space optional in multiple less or greater and ignore in config.json are not explicit enough. Can config.json use explicit enable and disable options?

Come to think of it, I also can't tell the difference between ignore and disable value. Are there any flags that gives different characteristics using these 2 values ? 🤔

[subframe7536]

Add some explainations.

enable and ignore are most commonly used, often as the most straightforward options. disable is chosen to deactivate specific font features.

I was initially very confused by the three options in the checkboxes on Font Freeze, but I figured that since it included a third option, there must exists some use cases for it. So, I followed the rule.

[subframe7536]

I will Close this issue:

• For issue1, the >: ligature is removed
• For issue2, the >>> ligature becomes conditional and optional, and no long affect normal use

[matthew-e-brown]

@subframe7536 I am only just now getting around to installing Beta28. Thank you for your responsiveness!

Personally, I think it would have made more sense to leave <</>> enabled by default. This issue only comes up when exactly three generic brackets are opened/closed in a row (<<</>>>), which is only a thing in some programming languages. I think the vast majority of users would prefer to have these ligatures enabled by default, since they are also commonly used as left- and right-shift operators, especially since the issue is basically unnoticeable with just two <</>> in a row (see second GIF in original post). Then ss07 could disable them for the few who don't want it (and then ss07 could be selectively enabled to disable it for problematic languages).

[subframe7536]

Valuable suggestion. I will take it into consideration.

[subframe7536]

Release in v7.0-beta29

[subframe7536]

I did some works to make >> more "smart", but failed to make it effect in IDEA: Its render engine will break font ligature when the glyphs are on different syntax ast node