
Ligatures in Programming Fonts: Hell No - tosh
https://practicaltypography.com/ligatures-in-programming-fonts-hell-no.html
======
jake-low
Used judiciously, ligatures can help make code more readable, not less.
Consider JavaScript's == and ===, and their inverses != and !==. I personally
find them difficult to visually distinguish on occasion (especially the
negative forms). Fira Code [0] replaces them with two-bar and three-bar equals
signs (something like =, ≠, ≡, and ≢, only wider; see the link for a
screenshot). I personally find these easier to distinguish from one another at
a glance. I'm sure it's not for everyone, but in my opinion at least these
ligatures improve readability.

I'm generally a fan of Practical Typography, but this post is unnecessarily
condescending. It's sort of laughable to claim that "this isn’t a matter of
taste" when users are making this choice in the privacy of their own editors.

[0]: [https://github.com/tonsky/FiraCode](https://github.com/tonsky/FiraCode)

~~~
dmos62
I'd argue the inverse.

In my experience removing the gaps makes some symbols harder to read. Like
distinguishing `==` and `===` without gaps is harder, though admittedly three-
bar helps. Also, I find the ligatures I've tried a bit of an eye-sore, but
that's just personal taste.

What's a more serious concern is the "dumbness" mentioned in the article and
the handling of ambiguous cases. To give my own example, in addition to those
in the article, I use a series of more than 3 equals signs as a delimiter in
my notes. With programming ligatures it looks distractingly bad. Normally it's
a continuous row of two-bars, but with them ligatured they look like morse
code divided into short groups of long two-bars. Essentially, when I'm writing
code or whatever, I don't want there to be someone guessing what I mean and
how I want something to look. Unless he guesses always right, he's a nuisance.
Sorry for the personification.

~~~
atoav
Well it is a matter of personal taste, isn’t it? For me it is just the
opposite, the visual appearance of the ligatures burned itself itnto my brain
in away that it is easier to spot when it is not there. Sometimes something
not converting to a ligature can also be a hint (e.g. for a wrong hyphen
beeing used etc)

~~~
type0
> Sometimes something not converting to a ligature can also be a hint (e.g.
> for a wrong hyphen beeing used etc)

So what languages actually benefit from this? haskell, clojure but maybe not
the usual C family ones?

~~~
atoav
No idea, I use rust and python with it.

------
captainmuon
Usually, the author is spot-on with his recommendations and I really enjoy
reading his website. So I was a bit surprised about this:

> When we’re using a serifed text font in ordinary body text, we don’t have
> the same considerations. An fi ligature always means f followed by i. In
> that case, ligature substitution that ignores context doesn’t change the
> meaning.

Maybe this is different in English typography - I'm a bit more proficient in
German - but ligatures do have semantic meaning. At least in German, they
should never cross a word boundary in composite words, for example Kaufleute
(merchants) is Kauf-leute (buy-people), so you would not use a "fl" ligature.
There are actually words where this resolves an ambiguity, I think.
Historically, this is the reason sometimes ss and sometimes ß is used. I
always assumed there were similar subtle rules in English.

As to the "ligatures" in programming fonts - I would not call them such,
problem solved. Rather, they are substitutions in the tradition of APL or vim
conceal mode - to get mathematical notation with a standard keyboard.

~~~
pjc50
Perhaps, but the automatic ligature substitution doesn't know that, and indeed
in Times "Kauflete" is rendered with a ligature. Probably because native
English speakers aren't used to accent or ligature rules.

Anyway, I too agree with the author; if you want ≥ to appear on your screen,
it should be in the source text as the UTF-8 bytes for U+2265 and the tooling
should understand it. Programming is too fragile to allow misunderstandings
between the bytes that are interpreted by the machine and the glyphs that the
programmer understands to be inserted.

Going much further back, there are the C trigraphs '??!' etc, for those whose
character sets don't contain '|'. I've not seen editors attempt to
automatically show those as the substitute characters either.

(Oh, and if you want to be unpopular, try entering unicode characters in your
language variable identifiers or git commit messages and see how much tooling
you can break...)

~~~
Freak_NL
Why would using non-ASCII characters (I assume that is what you mean by
Unicode characters) in a git commit message break anything sensible? It's
meant to be human readable text, and defaults to UTF-8 (although you can use
legacy encodings if you really must).

Any git hook processing stuff would just look for stuff it does understand
(like '([Cc]lose(s)?|[Ff]ix(es)?) #[0-9]+' or something similar) and ignore
the rest.

Scores of developers use non-ASCII characters as part of their native language
every day in git commit messages, and even non-BMP Unicode characters like
emoji work just fine.

~~~
aasasd
Well, I dunno if you consider GitHub branch names circa 2015 sensible...

------
wbond
> The problem is that ligature substitution is “dumb” in the sense that it
> only considers whether certain characters appear in a certain order. It’s
> not aware of the semantic context.

At least in Sublime Text this is not true. We tokenize the text according to
the rules in the syntax definition and then pass characters to be shaped, but
respecting token boundaries.

In fact, we’ve fielded a number of bug reports about ligatures not working,
and it is almost always that the syntax definition was tokenizing the = and
the > as separate tokens.

We also made the decision to only pass runs of symbols to the text shaping
engine, as opposed to runs of alphanumeric characters. This prevents ligatures
like fl that are usually not useful in a monospace layout such as a text
editor. There are also options to control the OpenType features for ligature
fine tuning.

~~~
gwenzek
Came here to say this ST handles ligatures very sensibly

------
tribby
> If you don’t believe me, try it for 10 or 15 years

nope, I still haven't ever run into the described issues. but that's not even
why I disagree with the author. if I _did_ run into an issue, it absolutely
wouldn't be the font's problem. this is akin to blaming a crypto algorithm for
a security flaw caused by a bad implementation. fonts are software and IDEs
can simply provide an option to disable ligatures. and, often, they do:

in sublime:
[https://www.sublimetext.com/docs/3/ligatures.html](https://www.sublimetext.com/docs/3/ligatures.html)

in vscode: [https://github.com/tonsky/FiraCode/wiki/VS-Code-
Instructions](https://github.com/tonsky/FiraCode/wiki/VS-Code-Instructions)

in atom: use CSS

~~~
shusson
> fonts are software and IDEs can simply disable ligatures.

Yeah but the author is suggesting that using a particular font will increase
the likelihood of a programmer introducing some syntactically correct but
erroneous code. But then he doesn't actually give any examples. So I don't buy
it either. Maybe certain languages are more susceptible?

------
onhn
The article would have been a lot better if there was at least one example of
where a coding ligature was a problem, rather than talking about feet and
inches

For instance it mentions the pairing => but provides no examples.

After reading I’m far from convinced that carefully curated language specific
ligatures are a bad idea.

~~~
hoseja
Here's an example:
[https://github.com/tonsky/FiraCode/issues/751](https://github.com/tonsky/FiraCode/issues/751)

~~~
LeonidasXIV
That's why e.g. Iosevka has language-specific ligations so you can chose
between the standard, the slightly extended ML ligatures and the whole set of
Coq craziness.

------
duskwuff
> So what’s the problem with programming ligatures? // They contradict
> Unicode.

The Unicode ligatures in the Alphabetic Presentation Forms block (U+0FB00 -
U+0FB4F) are only present for compatibility purposes, so that legacy texts in
encodings which contain precomposed ligatures can be losslessly reencoded
to/from Unicode. They aren't meant to represent the entirety of all ligatures.

~~~
WorldMaker
Also, the author's follow on implication that Unicode only encodes one version
of something that visibly looks the same is also false. It's exactly why we
have things like punycode in browser URL bars, and even various "normalization
standards" to compare multiple means of encoding similar characters.

Not to mention entire languages that build structure as complex combining
sequences, including emoji and its complex ligatures combining the Zero Width
Joiner and multiple emoji into single result emoji.

------
sklivvz1971
>Bottom line: this isn’t a matter of taste.

It is, quite unequivocally, a matter of taste. Please don't pass your
personal, unsubstantiated opinions as a matter of fact. :-)

~~~
diegoperini
100% agree. No editor comes with such font used as default. If a user wants to
add fancy ligatures, she has to set it up by herself. It is very unlikely for
such person to forget she is using ligatures in the middle of coding. Also,
text editors put the caret to a proper position if the selected text breaks a
ligature in the middle.

I personally see no problem using Fira Code aside from 10 seconds long brain
hiccups every once in while (once per year, maybe rarer). I've been using it
since 2015, on multiple editors including Xcode, Android Studio, iTerm2,
Sublime Text, Atom, VS Mac, VS Code and IntelliJ. I can't even remember which
one of these still doesn't support the proper rendering of ligatures, and yet
no issues for me so far.

------
OskarS
Setting aside the article for one second, I just want to mention that the
author is a hell of a font designer, and his Triplicate Code is my favorite
programming font at the moment [0]. It has all the styles you would want
(light strokes, heavy strokes, bold, italic, ...) as well as lovely serifs.
Most serif programming fonts are slab serifs, but not Triplicate. These ones
are lovely and light things. It's a real pleasure to work in. Well worth the
cost if you care about such things.

[0]:
[https://practicaltypography.com/triplicate.html](https://practicaltypography.com/triplicate.html)

------
dmitriid
Fira Code's main problem is that it tries to be a font for all programming
languages which results in some weird behaviours here and there.
Unfortunately, there's no good way to have a font have sets of ligatures per
<whatever you're working with right now>.

That said, however, the article fails to provide a compelling argument against
ligatures.

1\. Fonts have nothing to do with Unicode. It's exactly the font's job to
provide any glyphs or ligatures it wants on top of provided characters.

2\. Programming languages have been long stuck in ASCII-land trying to emulate
symbols commonly used in other areas such as mathematics: -> and => _are_
arrows, == and === _are_ equality and congruence, >= and =< _are_ greater
than/less than or equal to, and the list goes on. These will never be easy to
type in their original form (unless you have APL's custom keyboard), so why
not present them as such?

3\. Computers have all but destroyed typography, and it's a good thing some of
it is coming back. Properly spaced numbers? Properly spaced and aligned
punctuation? Contextually correct punctuation? Yes, please, more!

So, what's the beef with ligatures? I don't know :) And yes, I've been using
Fira Code for several years now.

Ironically, the article says "well-intentioned amateur ligaturists are adding
dozens of new & strange ligatures." and uses what appears a "° DEGREE SIGN
U+00B0" that looks like a link to a footnote to denote external links.

 _Edit_ : minor corrections to readability

~~~
LeonidasXIV
> Unfortunately, there's no good way to have a font have sets of ligatures per
> <whatever you're working with right now>.

But there is, see Iosevkas ligature sets which switch different ligatures on
and off. The editor can just opt-in which one to use.

There might not be sufficient editor support for it but you can work around it
by generating different versions of it as default and then configure your
editor to use that font. Not elegant but workable.

~~~
dmitriid
That's what I meant when I wrote that sentence: either the font doesn't have
those sets, or the editors can't enable them, or there's no easy way to
support different fonts for different languages, or...

It's not limited to just programming. Font fallbacks for multi-language texts
(for example, English and Russian; that is, Latin and Cyrillic) in most (all?)
mediums are usually horrible, and usually revert to whatever the OS provides.

------
vortegne
I've been using fonts w/ ligatures in my IDEs for many years now with many
different languages. Not a single issue, ever.

I do get the point that author is making here, but it's only important for
these kinds of discussions in a vacuum, detached from reality, as self-
important typography and design blogs usually are.

------
beering
Fonts like Fira Code are attractive for the same reason animated cursors are
attractive - they give people a way to add fun little baubles to their working
environment. No, they don't benefit your productivity and in many cases make
it worse (e.g. confusing ligatures or buggy editor plugins) but decorations
are by definition not of utility.

~~~
BenjiWiebe
Decorations can't add utility? Does color-coding (tools|parts|areas) count?

------
mikekchar
If anybody wants an example of where ligatures will cause problems, try
playing a roguelike in a console using the Fira Code font with ligatures
turned on. It demonstrates that accidental collisions end up with completely
different glyphs. My first experience with this was with Dwarf Fortress in
text mode.

But... I have to say that this is the only place I've actually come across it.
I eventually decided that I don't like ligatures, personally, in my source
code. However, the chance of problems occurring is pretty remote.

~~~
svrtknst
> try playing a roguelike in a console using the Fira Code font with ligatures
> turned on

But... why? It's obviously not intended for that purpose. You would get
awkward results trying to program with a regular serif, too, but that's not a
fault of the entire category of serifs.

------
cseelus
Why do folks that don‘t want to use them even care?

It’s not that when they are used, different code is produced. As with the
editors color scheme, it’s just a personal choice everyone can live out within
the privacy of his or her editor.

Personally I find it nice to represent single logical tokens like => or ===
with just a single character.

~~~
ilikehurdles
I’m on your side with ligatures. Pry them from my cold dead hands. But given
that the author is a font designer he probably has had many heated discussions
on the matter and that’s probably why he cares so much.

------
dragonwriter
Ligatures work well enough when selected properly for the target language,
since the often substitute for what the language designer was using ASCII art
to approximate.

Still, Perl 6 I think has the better solution: use Unicode well with ASCII
fallbacks. Combine it with editor language modes that are aware of the
equivalents and do Unicode substitution when the ASCII combo is used, and you
get a situation all-around better than ligatures.

------
WkndTriathlete
I'm unconvinced, because as far as I'm concerned ligatures are a viewing
enhancement and have nothing to do with writing the code. Maybe there are
(extreme) edge cases where I might accidentally confuse a Unicode code point
with a ligature, but since those symbols are (relatively) difficult to access
on most keyboards to begin with, I don't think any practical difficulty would
ever present itself.

I've often thought that smarter IDEs should be able to recognize the language
and display code in the user's preferred style with better use of screen
space. For instance, a Java class could be displayed with the class signature
in a fixed header; enclosed methods could be displayed starting at the left,
instead of indented; stacks of annotations could be replaced by a gutter icon
with a hover/click to show/expand/close; methods could be grouped and ordered
by particular criteria; etc., all while the underlying source file remains
intact.

------
svrtknst
I've been using Fira Code pretty much since its inception, currently trying
out Hasklig.

I never want a programming font without ligatures ever again.

This article, to me, seems like a case where the authors' ire is proportional
to a) their understanding of the subject b) how relevant the topic is.

Because really, a) ligatures won't cause catastrophic failures by rendering
code illegible and b) it really, really doesn't matter all that much. Non-
destructive personal preference.

------
gnachman
It also makes the lives of terminal emulator developers much more difficult.
Won't someone think of the terminal emulator developers?

~~~
pjmlp
Luckly on many OS the terminal is just yet another graphical application, not
something trying to emulate 40 years old hardware.

~~~
saagarjha
(You're talking to the developer of iTerm2, which is a graphical application.
iTerm2 took a while to support ligatures:
[https://gitlab.com/gnachman/iterm2/issues/3568](https://gitlab.com/gnachman/iterm2/issues/3568))

~~~
pjmlp
The nick was unknown to me.

From the ticket it seems to me that the root cause was not handling text as
GUI applications are supposed to do(aka like Wordprocessors).

------
Lowkeyloki
I wouldn't use these fonts in documentation or on a blog. But I love them in
my editor, where only I need to understand the difference between the literal
characters and those tasty ligatures.

------
ken
I've never used ligatures like this, and I have no horse in this race, but I
don't find these arguments compelling.

1\. By this reasoning, Unicode contradicts itself. There's lots of codepoints
that I can't visually distinguish from one another, even when printed without
ligatures. If the quality of visual uniqueness is important, better stick to
printable ASCII.

2\. Every syntax-highlighter I've ever used, for any language more complex
than a Lisp, has been wrong, occasionally. Every IDE "find text" feature finds
useless results, occasionally, from lack of context, too. Again, if perfection
is your threshold for use, you're going to have to throw out half your editor.

If you want to go all Marie Kondo on your toolchain (like Chuck Moore has been
doing for decades), that's neat, but that doesn't sound like what he's
advocating here.

> If you don’t believe me, try it for 10 or 15 years.

Every time a programmer tells me this, and I ask around, I find that the
population is split. Seriously, you don't believe me that emacs is 1000 times
better than vi? Try it for a few years.

------
billpg
Is <= equivalent to ⇐ or ≤ ?

Personally, I'd love a keyboard that had a ≤ key and a programming language
that recognized that symbol.

~~~
b2gills
In Perl6 <= is equivalent to ≤

    
    
        say 4 ≤ 5; # True
        say 4 ≤ 4; # True
        say 4 ≤ 3; # False
    
        say 4 <= 5; # True
        say 4 <= 4; # True
        say 4 <= 3; # False
    

Specifically they are the exact same subroutine. (The normal operators are
just subroutines with a special name.)

    
    
        say &infix:« ≤ »  =:=  &infix:« <= »; # True
    

(The =:= operator is basically the same as pointer equivalence.)

The line which creates this equivalence is the following:

    
    
        my constant &infix:<≤> := &infix:«<=»;
    

[https://github.com/rakudo/rakudo/blob/b0dd44b006dc44da5695b2...](https://github.com/rakudo/rakudo/blob/b0dd44b006dc44da5695b28c53be52a5772f08a4/src/core/Numeric.pm6#L320)

------
atemerev
I use Fira Code constantly and consistently, with punctuation-rich language
(Scala); haven’t found any practical problems yet. Theoretically, there can be
inconsistencies; practically, it doesn’t happen.

If it is consistency and perfection everywhere you are looking to find,
software engineering in general might not be the best job for you.

------
lawn
I usually agree with the author, but not really here.

> They contradict Unicode

So what?

The ligatures are only supposed to look good in my editor, with my config, in
the programming language I use and for my eyes only. Nothing else matters.

> They’re guaranteed to be wrong sometimes

See previous point.

As long as it's good enough for my purposes in the context I use the font, it
doesn't matter if it breaks some edge case that makes the author upset.

> Bottom line: this isn’t a matter of taste.

It is a matter of context, which the author completely misses.

And yes, it's also a matter of taste. Everything design related is in parts
taste.

------
rumpelsepp
Once I got used to the look of the 0, I started to love Hack:
[https://sourcefoundry.org/hack/](https://sourcefoundry.org/hack/)

Ligatures always confused me...

------
polyterative
I love my ligatures in Hasklig. Can't imagine my lambda arrows or equality
comparisons without them

------
gnicholas
I thought programming fonts are typically monospaced, which means collisions
(which create the need for ligatures) aren't much of an issue. I agree that
ligatures aren't good in programming, but it just seems the need wouldn't be
that great. Or am I missing something?

~~~
mashehu
Ligatures in programming fonts usually don't want to solve the problem of
character collisions. Instead they transform rather weird symbol sequences
used in programing to something closer to symbols used in maths or how you
would write it by hand, e.g. != becomes ≠, =< becomes ≤, or === becomes ≡.
More examples are in the repo readme:
[https://github.com/tonsky/FiraCode](https://github.com/tonsky/FiraCode)

~~~
gnicholas
Ah, gotcha. Based on the examples given (e.g., Th), I got the sense he was
talking about letters.

------
g105b
I see font ligatures in the same light as tab characters. They are
configurable in the editor and don't affect the source code, but enhance
visual clarity while not forcing programming languages to now have to support
custom operators such as "≥".

------
RenRav
I've always hated ligatures in general and consequently all webfonts, google
fonts, etc are purged from my web browsing. But they also have no place in a
monospaced font when two characters combine.

------
panic
Previously:
[https://news.ycombinator.com/item?id=14830797](https://news.ycombinator.com/item?id=14830797)

------
juancn
I love them. I even use Fira Code on the terminal. It's a matter of personal
preference IMHO.

------
rich-tea
I suppose Adobe want to draw attention to ligatures because they want to draw
attention to the fact that their software supports them. That "Th" ligature is
pretty bad.

