Conflict of multiple greater ligature >> / >>>

[subframe7536]

Introduction

There exists a long-standing conflict in programming font ligatures: >>. I searched through most popular open-source monospace fonts' GitHub repositories, and in their issues, there is always at least one open issue complaining about >> ligature. Further responses are rare, or just provide a style set to disable it.

Conflict

In my experience, there exist two kinds of usages of >>:

1. Operator: In most programming languages, >> is a bitwise operator, starting or ending with a number or variable, and the language formatter often inserts a space between the operator and number/variable.
2. Part of generic type/template: In some modern programming languages, generic type (Typescript, Java, Rust) or template (C++) is often used for powerful DX improvements and provides compile-time safety. In some complex use cases, >> is part of the end symbol, like Array<Partial<T>>.

The main conflict is that if the ligature is enabled, the space between two > is reduced for beauty, but at the same time, > in Array<Partial<T>> will also be squeezed, and the balance between < and > is broken, see details in #233.

It will also render wrong syntax highlighting if you are using VSCode bracket pair colorization, like this Fira Code issue

History

V5 and V6

Before V6, I lacked coding experience and was struggling with exploring algorithms and design patterns. I had little time to deeply consider this issue. So I just followed the mainstream ways on ligature designation except for some unbearable parts.

V7 Beta 28 and 29

Issue #233 reminded me of this conflict, so I started to rethink the solution.

I presumptuously thought that everyone who replaced their default font with a programming font with ligatures would care about code formatting, so I simply changed the ligature rule to require that << / <<< should have a trailing space and >> / >>> should have a leading space, and set ss07 to disable them in V7 Beta28. But in fact, in this part, the font itself should not be opinionated, or at least, it should be a configurable option. Also, << / >> is more commonly used than <<< / >>> from my experience, so the limitations on << and >> were removed in V7 Beta29.

It works, but not so well.

Make it "smarter"

AFAIK, there is nothing like AI to make the font ligature "smart", not even a concept like Regular Expression. Ligatures are just "if-else" rules that make the font render engine efficiently match and replace the glyphs. Everything is "if-else" and hard-coded. So, the font ligature cannot be a perfect solution for all usages of >>.

So, I searched the use cases for >> in grep.app and listed the most common cases here:

Enable Cases:

1. 1>>1 / 1 >>1 / 1>> 1 / 1 >> 1
2. 1>>>1 / 1 >>>1 / 1>>> 1 / 1 >>> 1
3. a>>1 / a>>b / a1>>_var / 2>>$jsVar

Disable Cases:

1. C# or Kotlin:

// >>. with suffix property
int ICollection<KeyValuePair<string, object?>>.Count => Options.Count;

// >>? (Swift / Dart as well)
public Option<List<List<long>>?> ArrayArrayOfIntegerOption { get; private set; }

2. CPP:

// @VariableChar>> @VariableStartChar
ErrorOr<Optional<PhysicalAddress>> find_table(PhysicalAddress rsdp, StringView signature);

// >>^
virtual List<KeyValuePair<String^, ApiSetTarget^>>^ GetAll() = 0;

// >>&
const c10::List<std::optional<Tensor>>& optional_tensors

// >>*
template <typename T, typename std::enable_if_t<std::is_same_v<T, JsonNumber>>* = nullptr>

3. TypeScript:

// >> without any glyphs
type Fn = () => Promise<Record<string, number>>

// >>;
type List = Partial<Array<number>>;

// >>[
type Data = Array<Array<number>>['at']

// >> = (>>= is a operator)
const data1: Required<Partial<1>> = 1

// >>(
const data2 = new Array<Array<number>>()

// >>, >>{ / >> {
function data3(foo: Array<Array<1>>, bar: 0): Required<Partial<void>>{ }

Solution

So, I have to make a trade-off for the usages of >> since they are quite different. I finally chose to make generic type/template as the first-class support, based on my experience. I tried to make the ligature rule more context-sensitive: if >> has a leading variable or trailing symbol, the ligature will be disabled.

During this period, I encountered some things that I had not considered before, such as in VSCode, the Unicode of space is 0020 when copying, but it is 00A0 (non-breaking space) when displaying, which caused some rules to not take effect.

Result:

Exception

Although the ligature rules are context-sensitive, there are some exceptions due to the limitation of the render engine or the conflict of usages of >>:

• Conflict of single space bitwise operator (a>> b) and generic type on implements (class A<T extends Partial<Obj>> implements B).
• Conflict of <<Bin/binary, 0>>. in Erlang and ICollection<KeyValuePair<Key, Value>>.Property in C++ / C#.
• Different font styles will break the ligature.
• Context-sensitive ligature is not supported in JetBrains' IDE. I think it is because the words are splited based on the syntax AST nodes. I have no expectation about this feature, since their branded font is not supported to config OpenType features in their own products.

Make it "normal"

In V7 Beta30, you can disable the ligature rule by enabling the ss07 feature.

Conclusion

The ligature conflict of >> is a long-standing problem in programming font ligatures. To solve this conflict, I have to make a trade-off between the usages of >> as operator and generic type/template. My solution is to make the ligature rule more context-sensitive, and it is not perfect. But I believe that this solution is better than the previous ones in most cases.

If you have any suggestions or thoughts, feel free to leave a comment.

[matthew-e-brown]

Wow, I must say that I'm really impressed at the lengths you're going to to make such a versatile font. This level of attention to detail and listening to feedback is awesome. Like you say, most would just provide an option to disable the ligature and call it a day. I'm very happy to have found this typeface. Great work :)