Ligatures in Programming Fonts: Hell No(practicaltypography.com)
practicaltypography.com
Ligatures in Programming Fonts: Hell No
https://practicaltypography.com/ligatures-in-programming-fonts-hell-no.html
30 comments
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.
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.
The article is "ligatures are always wrong for everyone in code" and your position seems to be "ligatures are wrong for me and people who are reading my code in their editor".
I don't think anecdotes of cases where ligatures fail support a case for them being wrong for all people and all situations.
Personally, I've never had a single instance of them doing something dumb in 2+ years of using them. Never a single instance of them creating any ambiguity or failing to add clarity to my reading of code. Dumb in "theory" might be smart enough 99% of the time.
Just in the last couple months, I had to review code without the aid of a linter and they were invaluable.
I don't think anecdotes of cases where ligatures fail support a case for them being wrong for all people and all situations.
Personally, I've never had a single instance of them doing something dumb in 2+ years of using them. Never a single instance of them creating any ambiguity or failing to add clarity to my reading of code. Dumb in "theory" might be smart enough 99% of the time.
Just in the last couple months, I had to review code without the aid of a linter and they were invaluable.
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)
Well, at this point, `store` (=), `equal` (==), `equiform` (===) are even more readable, meaningful and accurate. Of course other terms such as `equivalent`, `equiquantal` `equireference`, `equieffective` and more are also possible.
Don't forget people read whole words, so they most likely don't spend much time on "==" recognition than they would with "equivalent". And with text completion, token length is an irrelevant metric on productivity as well.
Any non literal symbol used in code is an incentive to use more of them and turn code bases into harder to maintain "smart" obfuscated trick stacks.
On an historical perspective, how much people using "=" know where it comes from (nothing is more equal than two parallel lines), compared to how many people are able to make a good guess of the etymology of "equivalent" (same value)? Add to this observation that in the mid-time with the raise of non-euclidian geometry and topology the former insight is far less relevant nowaday.
Don't forget people read whole words, so they most likely don't spend much time on "==" recognition than they would with "equivalent". And with text completion, token length is an irrelevant metric on productivity as well.
Any non literal symbol used in code is an incentive to use more of them and turn code bases into harder to maintain "smart" obfuscated trick stacks.
On an historical perspective, how much people using "=" know where it comes from (nothing is more equal than two parallel lines), compared to how many people are able to make a good guess of the etymology of "equivalent" (same value)? Add to this observation that in the mid-time with the raise of non-euclidian geometry and topology the former insight is far less relevant nowaday.
My counter-argument: eslint and tools like that will warn or error when you use `==` when you should be using `===`, up to the point where `==` is considered a code smell (JS's 'loose' comparison has been the target of a lot of brouhaha)
While readability decreases the chances of bugs, it's not the only function of readability, not by a longshot.
To be fair, I find the "www" ligature to be a bit unnecessary, but apart from that I love the ligatures in Fira Code.
No I do not what some ide to start fucking about with code and introducing god only knows strange edge cases.
And I use profanity (Engineering language) for good reasons here can you imagine any other engineering discipline allowing this to happen - oh yes the CAD system added a ligature in the bridge design blueprints !!
And I use profanity (Engineering language) for good reasons here can you imagine any other engineering discipline allowing this to happen - oh yes the CAD system added a ligature in the bridge design blueprints !!
Ligatures in your editor don't change the underlying, code they just change the presentation of that code when you're viewing it. While a ligature supporting font may show you ≥, the underlying source file still contains the distinct characters >=
yes "up to a point lord copper". What what happens when this code is copy pasted, moved between machines in different countries or edited in multiple different editors you can get bizarre problems.
Even moveing excel between countries gets some very strange changes Eg changing diacritical's but they look very very similar.
Even moveing excel between countries gets some very strange changes Eg changing diacritical's but they look very very similar.
Absolutely nothing happens. Ligatures are a feature of fonts and font rendering engines. They do not affect the character codes. If you copy-paste from an editor configured with one of these fonts to an editor that isn't, you'll simply see the ordinary characters, because that's what was in memory the entire time.
The problem I have with ligatures in source code files is that it makes pairs of codepoints visually indistinguishable from a single codepoint.
For example, if I see "fl" in a string, is that "fl" or is it "fl"? That is, is it the codepoint sequence U+0066 U+006C turned into a ligated version visually, or is it U+FB02 the single codepoint?
Then I get paranoid: Did my text editor Helpfully convert the sequence of characters into the ligature character? The paranoia is probably unjustified, and would be seen as a bug if it weren't (probably), but a clear visual distinction would banish it entirely.
For example, if I see "fl" in a string, is that "fl" or is it "fl"? That is, is it the codepoint sequence U+0066 U+006C turned into a ligated version visually, or is it U+FB02 the single codepoint?
Then I get paranoid: Did my text editor Helpfully convert the sequence of characters into the ligature character? The paranoia is probably unjustified, and would be seen as a bug if it weren't (probably), but a clear visual distinction would banish it entirely.
It's one thing to write code with Unicode characters like ≢. That should be fine, and it's not difficult for programming languages to support it. (You could roll your own preprocessing tool).
Doing it with ligatures is not a great idea, because ligatures are a PITA (not always well supported) and add too much incidental complexity.
Doing it with ligatures is not a great idea, because ligatures are a PITA (not always well supported) and add too much incidental complexity.
> Fira Code [0] replaces them with [...]
And that's how it should be done. If you want something modified visually then you can modify it for yourself without pushing it on the rest of the world.
Edit: Disregard that, I was being dumb.
And that's how it should be done. If you want something modified visually then you can modify it for yourself without pushing it on the rest of the world.
Edit: Disregard that, I was being dumb.
but that's how programming ligatures work? Or, what is it that you're getting at?
Fonts with ligatures, such as Fira Code or Hasklig, work by replacing characters with a ligature. The actual source code is still "->" or "===" or "|>" or whatever it may be.
No one is "pushing it on the rest of the world"?
Fonts with ligatures, such as Fira Code or Hasklig, work by replacing characters with a ligature. The actual source code is still "->" or "===" or "|>" or whatever it may be.
No one is "pushing it on the rest of the world"?
Why are you ever using == in JS?
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.
> 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.
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...)
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...)
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.
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.
Well, I dunno if you consider GitHub branch names circa 2015 sensible...
I've used emoji and other astral planes characters in git commits and variable identifiers and haven't seen a tool break yet.
For an English example, some typographers would consider it better to avoid an "ff" ligature in "shelfful" (see The TeXbook, p.19).
The whole point of ligatures is that they are visually subtle enough that you don't consciously notice them, while removing distracting collisions of adjacent glyphs. The German rule seems entirely pointless and counterproductive.
That said, OP is wrong that ligatures would "break Unicode". The only ligatures that are directly encoded exist for historical reasons. Fonts can and should make contextual alternatives, and this is a normal part of typesetting for several languages.
Unicode breaks Unicode, it's not meant to be consistent, only compatible.
That said, OP is wrong that ligatures would "break Unicode". The only ligatures that are directly encoded exist for historical reasons. Fonts can and should make contextual alternatives, and this is a normal part of typesetting for several languages.
Unicode breaks Unicode, it's not meant to be consistent, only compatible.
> The German rule seems entirely pointless and counterproductive.
The rule provides visual hints for how to pronounce words. I think that is way more useful than slightly increasing the readability by joining glyphs without context.
The rule provides visual hints for how to pronounce words. I think that is way more useful than slightly increasing the readability by joining glyphs without context.
i makes a lot of sense, just think of
Kaufleute = Kauf ++ leute (merchant / trader, from kaufen = to buy)
Kaufläche = Kau ++ fläche (chewing surface / morsal surface from kauen = to chew)
Yes. I learned from this article that there are code points for ligature glyphs in unicode and it seems like a pretty bad idea, tbh.
> 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.
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.
Came here to say this
ST handles ligatures very sensibly
> 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
in vscode: https://github.com/tonsky/FiraCode/wiki/VS-Code-Instructions
in atom: use CSS
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
in vscode: https://github.com/tonsky/FiraCode/wiki/VS-Code-Instructions
in atom: use CSS
> 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?
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?
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.
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.
Here's an example: https://github.com/tonsky/FiraCode/issues/751
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.
> 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.
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.
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.
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.
>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. :-)
It is, quite unequivocally, a matter of taste. Please don't pass your personal, unsubstantiated opinions as a matter of fact. :-)
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.
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.
Exactly. My ligatures affect no other reader’s presentation. It is absolutely personal taste. What an absurd rant.
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
[0]: https://practicaltypography.com/triplicate.html
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
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
> Computers have all but destroyed typography, and it's a good thing some of it is coming back
Absolutely agree. Medium.com (as an example) has a bunch of flaws, but some of my favorite articles are their posts about bringing classical typography back to the modern web.
Absolutely agree. Medium.com (as an example) has a bunch of flaws, but some of my favorite articles are their posts about bringing classical typography back to the modern web.
> 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.
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.
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.
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.
> Unfortunately, there's no good way to have a font have sets of ligatures per <whatever you're working with right now>.
If your IDE (or text editor) can highlight and indent languages differently then it can certainly switch font or toggle a font property to select a ligature variant set.
If your IDE (or text editor) can highlight and indent languages differently then it can certainly switch font or toggle a font property to select a ligature variant set.
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.
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.
[deleted]
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.
Decorations can't add utility? Does color-coding (tools|parts|areas) count?
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.
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.
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.
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.
> 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.
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.
Sure, but try playing it with Comic Sans or Wingdings or Lobster or any other font and you'll realize why there are fonts for certain applications.
> 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.
I'm more looking for an example of where ligatures will cause problems while programming.
I'm more looking for an example of where ligatures will cause problems while programming.
Coding with a dwarf fortress tile set is even worse :P
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.
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.
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.
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.
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.
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.
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.
It also makes the lives of terminal emulator developers much more difficult. Won't someone think of the terminal emulator developers?
Luckly on many OS the terminal is just yet another graphical application, not something trying to emulate 40 years old hardware.
(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)
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).
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).
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.
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.
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.
Is <= equivalent to ⇐ or ≤ ?
Personally, I'd love a keyboard that had a ≤ key and a programming language that recognized that symbol.
Personally, I'd love a keyboard that had a ≤ key and a programming language that recognized that symbol.
In Perl6 <= is equivalent to ≤
The line which creates this equivalence is the following:
say 4 ≤ 5; # True
say 4 ≤ 4; # True
say 4 ≤ 3; # False
say 4 <= 5; # True
say 4 <= 4; # True
say 4 <= 3; # False
say &infix:« ≤ » =:= &infix:« <= »; # True
The line which creates this equivalence is the following:
my constant &infix:<≤> := &infix:«<=»;
On Linux I love using the "Compose" key to type these unusual characters. It works better mnemonically than having special keys for everything.
One language that uses unicode symbols liberally is Agda. Since it is a proof assistant, being able to use mathematical symbols helps a lot. They even remap the backspace key on Emacs to act as a sort of Compose key for typing all the symbols.
One language that uses unicode symbols liberally is Agda. Since it is a proof assistant, being able to use mathematical symbols helps a lot. They even remap the backspace key on Emacs to act as a sort of Compose key for typing all the symbols.
If you want the symbol just to avoid typing an extra key, you can use a workaround.
Get a keyboard with some extra keys (or a small side-board) and just get a ≤ key. Then just program it as a macro for <=.
Wouldn't really solve the "programming language recognizing the symbol" Though that could probably be hacked in as well if you _really_ want to.
I mean, I know this is not ideal. I'm just throwing out bad ideas :D
Get a keyboard with some extra keys (or a small side-board) and just get a ≤ key. Then just program it as a macro for <=.
Wouldn't really solve the "programming language recognizing the symbol" Though that could probably be hacked in as well if you _really_ want to.
I mean, I know this is not ideal. I'm just throwing out bad ideas :D
> I'd love a keyboard that had a ≤ key
On a mac, hit option + "<".
I can't help you with the language, though.
On a mac, hit option + "<".
I can't help you with the language, though.
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.
If it is consistency and perfection everywhere you are looking to find, software engineering in general might not be the best job for you.
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.
> 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.
Once I got used to the look of the 0, I started to love Hack: https://sourcefoundry.org/hack/
Ligatures always confused me...
Ligatures always confused me...
I love my ligatures in Hasklig.
Can't imagine my lambda arrows or equality comparisons without them
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?
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
Ah, gotcha. Based on the examples given (e.g., Th), I got the sense he was talking about letters.
I always code in a proportional font, but even there the typical operator character sequences like == don't collide or run together.
OTOH, perhaps because I use a proportional font, I would be curious to try one with operator ligatures. The interesting thing is that a ligature for !== wouldn't have to be three characters in width to preserve alignment, it could actually be the normal ≢ glyph.
This suggests an experiment: I'm already using a modified version of Trebuchet MS (my favorite coding font, but the tilde sucks so I swapped one in from a different font), so I could probably add some ligatures like the one above using existing glyphs instead of having to draw them by hand. I will have to try it sometime!
OTOH, perhaps because I use a proportional font, I would be curious to try one with operator ligatures. The interesting thing is that a ligature for !== wouldn't have to be three characters in width to preserve alignment, it could actually be the normal ≢ glyph.
This suggests an experiment: I'm already using a modified version of Trebuchet MS (my favorite coding font, but the tilde sucks so I swapped one in from a different font), so I could probably add some ligatures like the one above using existing glyphs instead of having to draw them by hand. I will have to try it sometime!
Could you share a screenshot of your editor with Trebuchet? I would never think of it (or any other proportional font) as an adequate font for coding, so I’m pretty curious to see what it looks like.
Sure, here's an example:
https://imgur.com/482puD4
If the text looks huge, it's because I took the screenshot on a high-DPI device with 200% scaling, sorry about that. Imagine it half the size and you will have a better idea of how it actually looks.
In any case, the point is that code like this just doesn't depend on monospacing. If you viewed the same code in a monospaced font, it would look pretty much the same except for the font choice.
The key is to not do column alignment tricks that assume a monospaced font, like this:
https://imgur.com/482puD4
If the text looks huge, it's because I took the screenshot on a high-DPI device with 200% scaling, sorry about that. Imagine it half the size and you will have a better idea of how it actually looks.
In any case, the point is that code like this just doesn't depend on monospacing. If you viewed the same code in a monospaced font, it would look pretty much the same except for the font choice.
The key is to not do column alignment tricks that assume a monospaced font, like this:
doSomething(oneParam,
anotherParam);
doSomething(
oneParam,
anotherParam
);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 "≥".
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.
I love them. I even use Fira Code on the terminal. It's a matter of personal preference IMHO.
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.
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