8 ms·

Ligatures in programming fonts

108 points by matiasz 9y ago

warrenm 9y ago
I didn't even know those were a thing But in a monospace font? No. No. No. no. No. Epicly bad plan to use something like that to display code
- detaro 9y ago
  What's bad about them? (I find the arguments in the link interesting, but not all that convincing)
  - zepolen 9y ago
    Can't guarantee 80 characters length easily.
    - rossy 9y ago
      This isn't a problem with ligatures that are designed to take up as much space as the characters they replace. Fira Code seems to have been designed with this in mind, so for example, the === ligature is exactly three times as wide as a normal character.
    - deleted 9y ago
      [deleted]
  - nvivo 9y ago
    I work with someone who uses them and I find it impossible to read his screen. Unless you work completely alone, it's a terrible idea.
    - larma 9y ago
      *Unless all people that might ever look at my screen are used to them. If you work with people over the internet, it doesn't matter because they can disable ligatures and still read your code. And obviously it's not a problem if people know them and are looking on your screen. But yeah, if you're doing pair programming and first dev is used to them and the second dev is not, that's a problem. The question is, is the solution that the second dev learns them or that the first dev stops using them - both will obviously dislike changing the way they like to code...
- jmcdiesel 9y ago
  Have you tried it? Its actually quite nice. You don't have like it yourself, but you don't need to declare it bad for everyone else
- joshka 9y ago
  The context of this is a recent article https://news.ycombinator.com/item?id=14821446 https://news.ycombinator.com/item?id=14821446
idle_zealot 9y ago
I use fonts with ligatures while programming because they're more expressive of intent. Many languages use a combination of characters to form a single meaningful token, such as JS with =>. This token is meant to appear similar to an arrow, and has nothing to do with = or >. In this case, I find it preferable to draw a ⇒.
- pdkl95 9y ago
  > they're more expressive of intent. You don't control which font will be used when viewing your source, so nothing extra is being expressed to other people about your intent. Using a font with ligatures in your editor when you program doesn't record anything extra in the source code. > ⇒ I find it strange that you include the proper way of doing this instead of using font ligatures: use the proper Unicode code point. Some languages already support Unicode operators, such as Perl 6 which, for example, accepts « » as a synonym for << >>. https://perl6advent.wordpress.com/2015/12/07/day-7-unicode-perl-6-and-you/ https://perl6advent.wordpress.com/2015/12/07/day-7-unicode-p...
  - seanmcdirmid 9y ago
    Unicode sucks for this kind of thing, since it would go on disk. Even if they don't go on disk, you have to figure out how to break them up into multiple characters so they can be edited (so ⇒ must be two characters, which is messy). No, Unicode isn't the answer. It is the answer to deali with someone who isn't using a specific font, like readers on hackernews. Ligatures are a cake and eat it to. To those who don't care for them, they simply don't see them. As they are under control of the font, editors don't need special support either.
    - emn13 9y ago
      The fact that they go on disk is a pro, not a con; and the fact that they're one character not multiple is also a pro and a not a con: what's the point of the individual characters? Those were merely introduces as a necessary workaround to cope with input limitations. Kind of like C trigraphs - and nobody uses those because they want to.
panic 9y ago
The first problem isn't really a problem, since ligatures are provided by fonts, not character encodings. From the Unicode FAQ on ligatures and digraphs (http://unicode.org/faq/ligature_digraph.html http://unicode.org/faq/ligature_digraph.html): "The existing ligatures exist basically for compatibility and round-tripping with non-Unicode character sets. Their use is discouraged. No more will be encoded in any circumstances. "Ligaturing is a behavior encoded in fonts: if a modern font is asked to display “h” followed by “r”, and the font has an “hr” ligature in it, it can display the ligature. Some fonts have no ligatures, some (especially for non-Latin scripts) have hundreds. It does not make sense to assign Unicode code points to all these font-specific possibilities." The second problem still stands, though, especially since these sequences of characters can be tokenized differently in different programming languages. IMO, if you're going to have character replacement like this, it should be a configurable editor feature like syntax highlighting.
- robert-boehnke 9y ago
  Isn't the choice of font inherently an editor feature like syntax highlighting?
  - gvx 9y ago
    I don't think they're talking about the choice of font, but instead the choice of replacing certain character sequences (e.g. ->) with glyphs (e.g. →).
- lucideer 9y ago
  I don't know what it would do to editor rendering performance, but disabling the `liga` OpenType flag for selections detected as strings would solve the majority of instances of #2 All in all though, this is a purely local dev preference matter - your editor ligature settings never affect the committed code, so neither are really a problem in practice.
- Datenstrom 9y ago
  This is exactly what I was going to say, and that one big issue I had when experimenting with ligatures for Hylang (a dialect of LISP) was that it did not keep the spacing of the original character combinations. While I thought the ligatures were much more concise, when they were disabled it shifted things around which ruined the indentation. It made the code ugly and hard to read for anyone not using them, so I had to give them up. Hopefully one day we can all have language specific characters that make our code more concise. Until then I'll stick to fonts that keep the spacing of the original intact.
Arcanum-XIII 9y ago
It seems there is some confusion for the author between the display part and the on disk part. text will not be saved with the ligature, it will still be pure unadorned text when saved... and for the confusion that could arise between a simple quote and a typographic one, it's not coming from the font but from the editor rendering engine (word does those kind of change, IntelliJ does not for example, but both can display correctly ligature)
- yorwba 9y ago
  I'm sure the author is well aware of the difference between encoding and display, since they have apparently designed their own fonts. However, their argument seems to be that since ligatures are just a hack to make plain text look like something fancy, you end up with confusing interactions due to the lack of context. Now I don't think this is likely to cause lots of problems in practice, since most people won't use both ligatured => and Unicode ⇒ in the same Haskell code; but in principle the potential for confusion is there. Imagine if some clever font designer made ' look like ` when between a space and a letter, the font would be unusable in any language where that is an important distinction. Personally, I'm not going to use ligatures for coding, firstly because I'm accustomed to the "normal" look and secondly because fcitx makes it really easy to type arbitrary Unicode when I want it.
  - rossy 9y ago
    I'm aware that Butterick is the author of several fonts, but this article has a surprising amount of vitriol from someone who should know that the choice of a programming font doesn't affect anyone but the programmer who chose it. During the article, he takes several opportunities to point out that his opinions are actually facts. Typographers usually have a lot of responsibility because their decisions can affect the readability of text for many other people, and this is why sage advice from experienced typographers is usually very handy, but in this case, he's complaining about something that each individual developer has to manually opt into. This is outside the realm of normal typography that he has authority in. The editor settings of an individual developer are extremely personal. Developers don't follow trends just for the sake of it. They set up their environment in the way they believe is most productive for them, because they know only their output matters. If an individual developer believes they are more productive with Fira Code, that's nothing a typographer should lose sleep over. If I believe that I'm ten times more productive when I code in Papyrus, that's no one's business but my own.
wmil 9y ago
The article lists a bunch of non-issues. Yes, you can create confusion by abusing unicode. But that's not new. C++ allows zero width spaces in identifiers. There's a guy on reddit who uses characters from Canadian Aboriginal Syllabics block to have angle braces in Go identifiers. Yes, they are guaranteed to be wrong sometimes. The big one is the <<< ligature makes the merge conflict zipper look strange. But it's incredibly obvious when they are wrong. So it's not an issue in practise. The reality is that no one is making anyone use a ligature font, and some people like them. If it's causing a problem then you can spend ten seconds changing your font.
- sneak 9y ago
  I gifted that guy gold for the sheer audacity of the thing.
  - jwilk 9y ago
    How much gold?
Stenzel 9y ago
I agree with the article, but the arguments the author gives are not quite spot-on. Ligatures render code unreadable, there is no way to see how to enter a particular character sequence that is shown as a ligature. They might beautify code for some individuals, but they should never be used for showing code in an public or explanatory context, like on the web. Some operators are no longer recognisable, a few just look wrong - a clear case where simplicity and functionality is sacrificed for style.
- Libbum 9y ago
  > they should never be used for showing code in an public or explanatory context This I can definitely agree with. The readability issue, in my opinion, is fine and coarse grained. If I'm scanning my own code, having ligatures on is quicker for me to understand and is ultimately more readable. But (and this is a large but), when editing my own code, ligatures are useless and in the way. Thus I set my editor to remove all ligatures on active/highlighted lines.
  - OJFord 9y ago
    I do this too, and with other 'prettifiers' like indent line characters. I use vim, so I find it great to have them in normal mode, and then disabled (set conceal =0) on entering insert mode.
- zimpenfish 9y ago
  > they should never be used for showing code in an public or explanatory context, like on the web Or a book like "The TeX Book"[1]? [1] I believe it's done as pre-render replacement rather than in the font itself but the principle is the same.
mg794613 9y ago
Ugh to answer the last line of the author: I have been using them for that long and the up and downsides are very well known to me. He has an subjective opinion about them, states them as facts 'and everyone who thinks differently is just stupid' OK author...
- gboudrias 9y ago
  Wow you weren't kidding. I have no opinion on the matter but that's just arrogant.
  - andyfleming 9y ago
    This isn't just some blogger though. Matthew Butterick wrote http://practicaltypography.com/ http://practicaltypography.com/ .
    - OJFord 9y ago
      A self-published eBook that acknowledges a lack of funding on the main page? Maybe it is required reading in typography circles, but to someone reading the submission who merely uses a font, this doesn't seem much of a credential.
      - kennethfriedman 9y ago
        "A self-published eBook that acknowledges a lack of funding on the main page?" is kind of a low blow. He's doing something really interesting with the funding model of practicaltypography, that I believe should be praised.
        OJFord 9y ago
        I'm not meaning to deal any blows at all, low or otherwise. I'm merely explaining that to the reader not a student of typography, there's not really any indication that this should be taken with more authority than 'some blog author' per comments above.
frou_dh 9y ago
Ligatures in programming fonts really seem like something you'd only get into in the midst of a hardcore procrastination bout.
sk0g 9y ago
Q: Should random people on the internet dictate what you do and like? A: Hell no I quite like the ligatures that come with Fira Code, and most of the author's issues are not applicable to it. Maybe they should spend more than 5 minutes trying things out.
anorakoverflow 9y ago
The author's point about "dumb" ligatures doesn't really hold up: While the "fi" ligature will always mean "f followed by i" its use is not always correct. For example, in German compound nouns, you do not set a ligature between the two nouns. For instance, "Kaufläche" (Kau: chewing, + Fläche: area) should be written with ligature, while in "Kaufleute" (Kauf: purchase, + Leute: people, = merchants) the ligature should be avoided.
- rocqua 9y ago
  Are there any font specifications that allow for this kind of distinction?
  - mrob 9y ago
    Every font with ligatures allows for this, because they also include glyphs for the component parts of the ligatures. It's the responsibility of the typesetting software to enable or disable ligatures as required, eg. with this TeX package for selective suppression of ligatures: https://www.ctan.org/pkg/selnolig?lang=en https://www.ctan.org/pkg/selnolig?lang=en
- crazygringo 9y ago
  Wow, that's fascinating -- do you have a reference for that? I'd love to learn more, especially as to why -- it seems like that would just result in ugly typography. Or is it solely about the bar of the initial "f" connecting to the next letter?
  - Johnny_Brahms 9y ago
    Well, typography is often about readability. Removing the word boundary in compound nouns isn't really helpful since it removes a boundary that conveys meaning. There were some examples of nouns where you should avoid ligatures in the TeX docs iirc. Shelfful and selffullfilling are the only ones I remember. In German (every single fff on any page that bothers to set their own fancy-pants font) and swedish text you see it all the time, often coming from self-proclaimed typesetting/font nerds.
nvivo 9y ago
I work with someone who uses ligatures. Everytime I need to see his screen is a problem, I can never recognize what exactly the characters mean. Yes, you get used to it if you use it, but if you don't, working with other people becomes a problem. I thought it was a bad idea the first time I saw it, and after seeing it in real code I still think the same thing.
- ordu 9y ago
  Yes, I hate seeing code any way except precisely tuned emacs. I like small sized characters, but most of fonts looks ugly, you'll need use antialiasing to preserve shape, but some chars becomes unreadable with antialiasing. Except of font choosing I'd like to see familiar color theme. And when I see code in someone's else editor its hard to read. But, you know, others didn't like my emacs setup, they says that its hard to read in such small sizes, and my color theme with dark background is bad for their eyes. Strange people, what on earth make them think, that I should be considering their eyes health while choosing font and color theme for myself?
qarioz 9y ago
Ligatures are for personal usage only. If you are doing presentation to me and use ligatures, I will judge you.
- MarkMMullin 9y ago
  I would argue it's not a one size problem - I use Fira for machine learning heavy code, which is primarily math, and ligatures for the various multicharacter operators make it more readable. Judge me, fine. But judge me in context please :-)
SCdF 9y ago
Honestly, this sounds like the kind of argument you could present about how syntax highlighting is a terrible idea. It might be wrong! I don't use ligatures, but I really don't see a problem with other people using them. It's fine, it's a style preference thing, that, like fonts and colour schemes, is as much fashion and personal preference as it is anything. But it's fine.
- toast0 9y ago
  I think this comment gets at the root of the issue. This is syntax highlighting, but it's done by the font rendering engine and it has no context. Syntax highlighting without context is not really a good experience. The highlighter needs to know what language you're using, and a pretty good idea of how to parse it. And the comment on ligatures below points out, this is actually true of ligatures for human languages as well, but I doubt the font engines are properly tuned for that either. I'd make an exception for the 'obvious' ligatures like gg gy etc where the descenders were overlapping without a ligature. That shouldn't be an issue in a monospaced context though.
- eridius 9y ago
  If your syntax highlighting is wrong, it's buggy. Proper syntax highlighting is 100% correct.
  - larma 9y ago
    Correct syntax highlighting is subjective, because color selection is a matter of taste.
    - gaius 9y ago
      Nope, you or I may think reserved words should be red or blue, but either the list of words that get highlighted is correct, or it isn't.
  - falcolas 9y ago
    Depending on your language, proper syntax highlighting (without parsing the entire program) is nearly impossible. For example, in C, what highlight category do you give to '*c'? A declaration, a dereference, or a multiplication call? In Lisp, is the first element of a list a macro or a function (or a value)? If there's a reader macro, it gets even harder.
abritishguy 9y ago
I use ligatures in atom and they are 100% aware of context. I disable them in contexts where they don't make sense e.g comments and I disable them on the line the cursor is on. I've not had any issues. The => ligature looking like the right arrow character is just like a cyrillic A looking like a latin A - it's a problem that never manifests itself. The author has a very subjective opinion that they try and present as fact.
captainmuon 9y ago
I think ligatures can be a great feature, but they should not be decided by the font, but by the editor. So you can can destinguish between 'input >> var' and 'vector<vector<int>>' and render the literature in one case but not the other. This and more creative text decorations can be really helpful to read code. Other examples are rendering css colors inline, rendering of tables and formulas in emacs, ...
- kd5bjo 9y ago
  That's a hard one to get right; for a long time, C++ compilers would tokenize 'vector<vector<int>>' incorrectly and throw a syntax error -- the final two angle brackets had to be separated by a space for the code to compile.
  - deleted 9y ago
    [deleted]
- lucideer 9y ago
  They aren't implicitly decided by the font, they are supported (or not supported) by the font and explicitly decided by the editor, so your recommendation is the case in practice. i.e. OpenType fonts optionally accept a range of settings flags to toggle various features. For standard ligatures this is the `liga` flag, this flag is off by default and an editor sets the flag to display ligatures (if the particular font supports that flag).
  - captainmuon 9y ago
    Really? That would be nice. Last time I checked, Atom was one of the only editors that supported it anyway, and it just applied ligatures indiscriminately. Same for the terminals that supported ligatures, I don't even know how e.g. vim would signal to a terminal to use a ligature.
mrkgnao 9y ago
> The problem is that ligature substitution is “dumb” in the sense that it only considers whether certain characters appear in a certain order. It doesn’t have any awareness of the semantic context. True, which is why Iosevka has language-specific ligatures that a sufficiently smart editor (I think the "JS types", like Atom/VSCode, have CSS for this) can use to ligate (?) intelligently.
VeejayRampay 9y ago
Am I the only one thinking that "www" using Fira Code is unreadable?
hamstergene 9y ago
They call it ligatures, but prettifying --> to a long arrow is quite out of scope of historical and practical meaning of typographic ligature. It's abuse of typesetter to scratch one's typography / graphic design itch, no less.
ktpsns 9y ago
mnm
ktpsns 9y ago
Interestingly, nobody mentioned Mathematica's (Wolfram langauge) approach of getting Unicode characters into code. "High level" mathematical symbols can be used in Wolfram language all over the place, for instance the arrow → indicating a Rule (http://reference.wolfram.com/language/ref/character/Rule.html http://reference.wolfram.com/language/ref/character/Rule.htm...) or ∞ indicating Infinity (http://reference.wolfram.com/language/ref/Infinity.html http://reference.wolfram.com/language/ref/Infinity.html). As Mathematica inherits the homoiconicity from LISP, ie. the paradigm "code is data", it abstracts the code representation (called "Forms", http://reference.wolfram.com/language/tutorial/FormsOfInputAndOutput.html http://reference.wolfram.com/language/tutorial/FormsOfInputA...). Every shortened code full of greek symbols can be written in a completely similar form in ASCII. Thus it is solely to the Mathematica notebook (a Qt-based GUI) to render the Unicode. The GUI also allows to quickly enter any named symbols with an approach like typing "[ESC] alpha [ESC]" and an α appears (cf. http://reference.wolfram.com/language/tutorial/SpecialCharacters-MathematicalAndOtherNotation.html http://reference.wolfram.com/language/tutorial/SpecialCharac...). I think this is the right approach: Let the beautification to be done by the code viewers. The approach to enter named symbols probably stems from (La)TeX where one writes "$\alpha$" to get α and is typical to Computer Algebra Systems. For instance, SageMath as well as SymPy allow to define something like a=var("alpha") and render it like α.
- MarkMMullin 9y ago
  Been awhile since I used MM, but I do remember this - personally, I like using Fira with my code, but that's because there's a disgusting amount of math in it and it makes the reading a lot easier - your implicit separation between representation and presentation is spot on IMO
wodenokoto 9y ago
Do ligatures really act like one character? I've never encountered not being able to select only the f ro the i in a 'fi'-ligature, but I don't really use ligatures outside of word processing.
- oneeyedpigeon 9y ago
  Some of the ligatures in Fira Code are so radically different from the characters they're substituting, that single-character selection would be incredibly confusing. How would it behave for the characters on the final line of the sample, for example?
mikelward 9y ago
Premise: don't make => look like ⇒, because ⇒ is already a separate thing. Then later: check out this font I made where 0 looks like Ø.
jstewartmobile 9y ago
Somewhat off-topic, but the explosion Unicode glyphs can lead to problems more serious than aesthetics: Punycode exploit: https://www.xudongz.com/blog/2017/idn-phishing/ https://www.xudongz.com/blog/2017/idn-phishing/ Greek question mark: https://stackoverflow.com/questions/26965331/javascript-prank-joke https://stackoverflow.com/questions/26965331/javascript-pran... Shameless plug: https://github.com/BourgeoisBear/A-E-S-T-H-E-T-I-C https://github.com/BourgeoisBear/A-E-S-T-H-E-T-I-C
broxp 9y ago
Fortress (a dead JVM programming language by Guy Steele) had an interesting approach for special characters: https://de.wikipedia.org/wiki/Fortress_(Programmiersprache)#Darstellung_des_Quelltextes https://de.wikipedia.org/wiki/Fortress_(Programmiersprache)#...
fuzzygroup 9y ago
Ignoring the Unicode issues, I installed all of these, switched to the retina version of each in my editor and I found none of them any better than what I had been using (Menlo). I'm certain that YMMV but at least for me, there was no improvement (languages tested with were Ruby, and ERB formatted HTML).

108 points by matiasz 9y ago

I didn't even know those were a thing But in a monospace font? No. No. No. no. No. Epicly bad plan to use something like that to display code

detaro 9y ago
What's bad about them? (I find the arguments in the link interesting, but not all that convincing)
- zepolen 9y ago
  Can't guarantee 80 characters length easily.
  - rossy 9y ago
    This isn't a problem with ligatures that are designed to take up as much space as the characters they replace. Fira Code seems to have been designed with this in mind, so for example, the === ligature is exactly three times as wide as a normal character.
  - deleted 9y ago
    [deleted]
- nvivo 9y ago
  I work with someone who uses them and I find it impossible to read his screen. Unless you work completely alone, it's a terrible idea.
  - larma 9y ago
    *Unless all people that might ever look at my screen are used to them. If you work with people over the internet, it doesn't matter because they can disable ligatures and still read your code. And obviously it's not a problem if people know them and are looking on your screen. But yeah, if you're doing pair programming and first dev is used to them and the second dev is not, that's a problem. The question is, is the solution that the second dev learns them or that the first dev stops using them - both will obviously dislike changing the way they like to code...
jmcdiesel 9y ago
Have you tried it? Its actually quite nice. You don't have like it yourself, but you don't need to declare it bad for everyone else
joshka 9y ago
The context of this is a recent article https://news.ycombinator.com/item?id=14821446 https://news.ycombinator.com/item?id=14821446

idle_zealot 9y ago

I use fonts with ligatures while programming because they're more expressive of intent. Many languages use a combination of characters to form a single meaningful token, such as JS with =>. This token is meant to appear similar to an arrow, and has nothing to do with = or >. In this case, I find it preferable to draw a ⇒.

pdkl95 9y ago
> they're more expressive of intent. You don't control which font will be used when viewing your source, so nothing extra is being expressed to other people about your intent. Using a font with ligatures in your editor when you program doesn't record anything extra in the source code. > ⇒ I find it strange that you include the proper way of doing this instead of using font ligatures: use the proper Unicode code point. Some languages already support Unicode operators, such as Perl 6 which, for example, accepts « » as a synonym for << >>. https://perl6advent.wordpress.com/2015/12/07/day-7-unicode-perl-6-and-you/ https://perl6advent.wordpress.com/2015/12/07/day-7-unicode-p...
- seanmcdirmid 9y ago
  Unicode sucks for this kind of thing, since it would go on disk. Even if they don't go on disk, you have to figure out how to break them up into multiple characters so they can be edited (so ⇒ must be two characters, which is messy). No, Unicode isn't the answer. It is the answer to deali with someone who isn't using a specific font, like readers on hackernews. Ligatures are a cake and eat it to. To those who don't care for them, they simply don't see them. As they are under control of the font, editors don't need special support either.
  - emn13 9y ago
    The fact that they go on disk is a pro, not a con; and the fact that they're one character not multiple is also a pro and a not a con: what's the point of the individual characters? Those were merely introduces as a necessary workaround to cope with input limitations. Kind of like C trigraphs - and nobody uses those because they want to.

panic 9y ago

The first problem isn't really a problem, since ligatures are provided by fonts, not character encodings. From the Unicode FAQ on ligatures and digraphs (http://unicode.org/faq/ligature_digraph.html http://unicode.org/faq/ligature_digraph.html): "The existing ligatures exist basically for compatibility and round-tripping with non-Unicode character sets. Their use is discouraged. No more will be encoded in any circumstances. "Ligaturing is a behavior encoded in fonts: if a modern font is asked to display “h” followed by “r”, and the font has an “hr” ligature in it, it can display the ligature. Some fonts have no ligatures, some (especially for non-Latin scripts) have hundreds. It does not make sense to assign Unicode code points to all these font-specific possibilities." The second problem still stands, though, especially since these sequences of characters can be tokenized differently in different programming languages. IMO, if you're going to have character replacement like this, it should be a configurable editor feature like syntax highlighting.

robert-boehnke 9y ago
Isn't the choice of font inherently an editor feature like syntax highlighting?
- gvx 9y ago
  I don't think they're talking about the choice of font, but instead the choice of replacing certain character sequences (e.g. ->) with glyphs (e.g. →).
lucideer 9y ago
I don't know what it would do to editor rendering performance, but disabling the `liga` OpenType flag for selections detected as strings would solve the majority of instances of #2 All in all though, this is a purely local dev preference matter - your editor ligature settings never affect the committed code, so neither are really a problem in practice.
Datenstrom 9y ago
This is exactly what I was going to say, and that one big issue I had when experimenting with ligatures for Hylang (a dialect of LISP) was that it did not keep the spacing of the original character combinations. While I thought the ligatures were much more concise, when they were disabled it shifted things around which ruined the indentation. It made the code ugly and hard to read for anyone not using them, so I had to give them up. Hopefully one day we can all have language specific characters that make our code more concise. Until then I'll stick to fonts that keep the spacing of the original intact.

Arcanum-XIII 9y ago

It seems there is some confusion for the author between the display part and the on disk part. text will not be saved with the ligature, it will still be pure unadorned text when saved... and for the confusion that could arise between a simple quote and a typographic one, it's not coming from the font but from the editor rendering engine (word does those kind of change, IntelliJ does not for example, but both can display correctly ligature)

yorwba 9y ago
I'm sure the author is well aware of the difference between encoding and display, since they have apparently designed their own fonts. However, their argument seems to be that since ligatures are just a hack to make plain text look like something fancy, you end up with confusing interactions due to the lack of context. Now I don't think this is likely to cause lots of problems in practice, since most people won't use both ligatured => and Unicode ⇒ in the same Haskell code; but in principle the potential for confusion is there. Imagine if some clever font designer made ' look like ` when between a space and a letter, the font would be unusable in any language where that is an important distinction. Personally, I'm not going to use ligatures for coding, firstly because I'm accustomed to the "normal" look and secondly because fcitx makes it really easy to type arbitrary Unicode when I want it.
- rossy 9y ago
  I'm aware that Butterick is the author of several fonts, but this article has a surprising amount of vitriol from someone who should know that the choice of a programming font doesn't affect anyone but the programmer who chose it. During the article, he takes several opportunities to point out that his opinions are actually facts. Typographers usually have a lot of responsibility because their decisions can affect the readability of text for many other people, and this is why sage advice from experienced typographers is usually very handy, but in this case, he's complaining about something that each individual developer has to manually opt into. This is outside the realm of normal typography that he has authority in. The editor settings of an individual developer are extremely personal. Developers don't follow trends just for the sake of it. They set up their environment in the way they believe is most productive for them, because they know only their output matters. If an individual developer believes they are more productive with Fira Code, that's nothing a typographer should lose sleep over. If I believe that I'm ten times more productive when I code in Papyrus, that's no one's business but my own.

wmil 9y ago

The article lists a bunch of non-issues. Yes, you can create confusion by abusing unicode. But that's not new. C++ allows zero width spaces in identifiers. There's a guy on reddit who uses characters from Canadian Aboriginal Syllabics block to have angle braces in Go identifiers. Yes, they are guaranteed to be wrong sometimes. The big one is the <<< ligature makes the merge conflict zipper look strange. But it's incredibly obvious when they are wrong. So it's not an issue in practise. The reality is that no one is making anyone use a ligature font, and some people like them. If it's causing a problem then you can spend ten seconds changing your font.

sneak 9y ago
I gifted that guy gold for the sheer audacity of the thing.
- jwilk 9y ago
  How much gold?

Stenzel 9y ago

I agree with the article, but the arguments the author gives are not quite spot-on. Ligatures render code unreadable, there is no way to see how to enter a particular character sequence that is shown as a ligature. They might beautify code for some individuals, but they should never be used for showing code in an public or explanatory context, like on the web. Some operators are no longer recognisable, a few just look wrong - a clear case where simplicity and functionality is sacrificed for style.

Libbum 9y ago
> they should never be used for showing code in an public or explanatory context This I can definitely agree with. The readability issue, in my opinion, is fine and coarse grained. If I'm scanning my own code, having ligatures on is quicker for me to understand and is ultimately more readable. But (and this is a large but), when editing my own code, ligatures are useless and in the way. Thus I set my editor to remove all ligatures on active/highlighted lines.
- OJFord 9y ago
  I do this too, and with other 'prettifiers' like indent line characters. I use vim, so I find it great to have them in normal mode, and then disabled (set conceal =0) on entering insert mode.
zimpenfish 9y ago
> they should never be used for showing code in an public or explanatory context, like on the web Or a book like "The TeX Book"[1]? [1] I believe it's done as pre-render replacement rather than in the font itself but the principle is the same.

mg794613 9y ago

Ugh to answer the last line of the author: I have been using them for that long and the up and downsides are very well known to me. He has an subjective opinion about them, states them as facts 'and everyone who thinks differently is just stupid' OK author...

gboudrias 9y ago
Wow you weren't kidding. I have no opinion on the matter but that's just arrogant.
- andyfleming 9y ago
  This isn't just some blogger though. Matthew Butterick wrote http://practicaltypography.com/ http://practicaltypography.com/ .
  - OJFord 9y ago
    A self-published eBook that acknowledges a lack of funding on the main page? Maybe it is required reading in typography circles, but to someone reading the submission who merely uses a font, this doesn't seem much of a credential.
    - kennethfriedman 9y ago
      "A self-published eBook that acknowledges a lack of funding on the main page?" is kind of a low blow. He's doing something really interesting with the funding model of practicaltypography, that I believe should be praised.
      - OJFord 9y ago
        I'm not meaning to deal any blows at all, low or otherwise. I'm merely explaining that to the reader not a student of typography, there's not really any indication that this should be taken with more authority than 'some blog author' per comments above.

frou_dh 9y ago

Ligatures in programming fonts really seem like something you'd only get into in the midst of a hardcore procrastination bout.

sk0g 9y ago

Q: Should random people on the internet dictate what you do and like? A: Hell no I quite like the ligatures that come with Fira Code, and most of the author's issues are not applicable to it. Maybe they should spend more than 5 minutes trying things out.

anorakoverflow 9y ago

The author's point about "dumb" ligatures doesn't really hold up: While the "fi" ligature will always mean "f followed by i" its use is not always correct. For example, in German compound nouns, you do not set a ligature between the two nouns. For instance, "Kaufläche" (Kau: chewing, + Fläche: area) should be written with ligature, while in "Kaufleute" (Kauf: purchase, + Leute: people, = merchants) the ligature should be avoided.

rocqua 9y ago
Are there any font specifications that allow for this kind of distinction?
- mrob 9y ago
  Every font with ligatures allows for this, because they also include glyphs for the component parts of the ligatures. It's the responsibility of the typesetting software to enable or disable ligatures as required, eg. with this TeX package for selective suppression of ligatures: https://www.ctan.org/pkg/selnolig?lang=en https://www.ctan.org/pkg/selnolig?lang=en
crazygringo 9y ago
Wow, that's fascinating -- do you have a reference for that? I'd love to learn more, especially as to why -- it seems like that would just result in ugly typography. Or is it solely about the bar of the initial "f" connecting to the next letter?
- Johnny_Brahms 9y ago
  Well, typography is often about readability. Removing the word boundary in compound nouns isn't really helpful since it removes a boundary that conveys meaning. There were some examples of nouns where you should avoid ligatures in the TeX docs iirc. Shelfful and selffullfilling are the only ones I remember. In German (every single fff on any page that bothers to set their own fancy-pants font) and swedish text you see it all the time, often coming from self-proclaimed typesetting/font nerds.

nvivo 9y ago

I work with someone who uses ligatures. Everytime I need to see his screen is a problem, I can never recognize what exactly the characters mean. Yes, you get used to it if you use it, but if you don't, working with other people becomes a problem. I thought it was a bad idea the first time I saw it, and after seeing it in real code I still think the same thing.

ordu 9y ago
Yes, I hate seeing code any way except precisely tuned emacs. I like small sized characters, but most of fonts looks ugly, you'll need use antialiasing to preserve shape, but some chars becomes unreadable with antialiasing. Except of font choosing I'd like to see familiar color theme. And when I see code in someone's else editor its hard to read. But, you know, others didn't like my emacs setup, they says that its hard to read in such small sizes, and my color theme with dark background is bad for their eyes. Strange people, what on earth make them think, that I should be considering their eyes health while choosing font and color theme for myself?

qarioz 9y ago

Ligatures are for personal usage only. If you are doing presentation to me and use ligatures, I will judge you.

MarkMMullin 9y ago
I would argue it's not a one size problem - I use Fira for machine learning heavy code, which is primarily math, and ligatures for the various multicharacter operators make it more readable. Judge me, fine. But judge me in context please :-)

SCdF 9y ago

Honestly, this sounds like the kind of argument you could present about how syntax highlighting is a terrible idea. It might be wrong! I don't use ligatures, but I really don't see a problem with other people using them. It's fine, it's a style preference thing, that, like fonts and colour schemes, is as much fashion and personal preference as it is anything. But it's fine.

toast0 9y ago
I think this comment gets at the root of the issue. This is syntax highlighting, but it's done by the font rendering engine and it has no context. Syntax highlighting without context is not really a good experience. The highlighter needs to know what language you're using, and a pretty good idea of how to parse it. And the comment on ligatures below points out, this is actually true of ligatures for human languages as well, but I doubt the font engines are properly tuned for that either. I'd make an exception for the 'obvious' ligatures like gg gy etc where the descenders were overlapping without a ligature. That shouldn't be an issue in a monospaced context though.
eridius 9y ago
If your syntax highlighting is wrong, it's buggy. Proper syntax highlighting is 100% correct.
- larma 9y ago
  Correct syntax highlighting is subjective, because color selection is a matter of taste.
  - gaius 9y ago
    Nope, you or I may think reserved words should be red or blue, but either the list of words that get highlighted is correct, or it isn't.
- falcolas 9y ago
  Depending on your language, proper syntax highlighting (without parsing the entire program) is nearly impossible. For example, in C, what highlight category do you give to '*c'? A declaration, a dereference, or a multiplication call? In Lisp, is the first element of a list a macro or a function (or a value)? If there's a reader macro, it gets even harder.

abritishguy 9y ago

I use ligatures in atom and they are 100% aware of context. I disable them in contexts where they don't make sense e.g comments and I disable them on the line the cursor is on. I've not had any issues. The => ligature looking like the right arrow character is just like a cyrillic A looking like a latin A - it's a problem that never manifests itself. The author has a very subjective opinion that they try and present as fact.

captainmuon 9y ago

I think ligatures can be a great feature, but they should not be decided by the font, but by the editor. So you can can destinguish between 'input >> var' and 'vector<vector<int>>' and render the literature in one case but not the other. This and more creative text decorations can be really helpful to read code. Other examples are rendering css colors inline, rendering of tables and formulas in emacs, ...

kd5bjo 9y ago
That's a hard one to get right; for a long time, C++ compilers would tokenize 'vector<vector<int>>' incorrectly and throw a syntax error -- the final two angle brackets had to be separated by a space for the code to compile.
- deleted 9y ago
  [deleted]
lucideer 9y ago
They aren't implicitly decided by the font, they are supported (or not supported) by the font and explicitly decided by the editor, so your recommendation is the case in practice. i.e. OpenType fonts optionally accept a range of settings flags to toggle various features. For standard ligatures this is the `liga` flag, this flag is off by default and an editor sets the flag to display ligatures (if the particular font supports that flag).
- captainmuon 9y ago
  Really? That would be nice. Last time I checked, Atom was one of the only editors that supported it anyway, and it just applied ligatures indiscriminately. Same for the terminals that supported ligatures, I don't even know how e.g. vim would signal to a terminal to use a ligature.

mrkgnao 9y ago

> The problem is that ligature substitution is “dumb” in the sense that it only considers whether certain characters appear in a certain order. It doesn’t have any awareness of the semantic context. True, which is why Iosevka has language-specific ligatures that a sufficiently smart editor (I think the "JS types", like Atom/VSCode, have CSS for this) can use to ligate (?) intelligently.

VeejayRampay 9y ago

Am I the only one thinking that "www" using Fira Code is unreadable?

hamstergene 9y ago

They call it ligatures, but prettifying --> to a long arrow is quite out of scope of historical and practical meaning of typographic ligature. It's abuse of typesetter to scratch one's typography / graphic design itch, no less.

ktpsns 9y ago

mnm

ktpsns 9y ago

Interestingly, nobody mentioned Mathematica's (Wolfram langauge) approach of getting Unicode characters into code. "High level" mathematical symbols can be used in Wolfram language all over the place, for instance the arrow → indicating a Rule (http://reference.wolfram.com/language/ref/character/Rule.html http://reference.wolfram.com/language/ref/character/Rule.htm...) or ∞ indicating Infinity (http://reference.wolfram.com/language/ref/Infinity.html http://reference.wolfram.com/language/ref/Infinity.html). As Mathematica inherits the homoiconicity from LISP, ie. the paradigm "code is data", it abstracts the code representation (called "Forms", http://reference.wolfram.com/language/tutorial/FormsOfInputAndOutput.html http://reference.wolfram.com/language/tutorial/FormsOfInputA...). Every shortened code full of greek symbols can be written in a completely similar form in ASCII. Thus it is solely to the Mathematica notebook (a Qt-based GUI) to render the Unicode. The GUI also allows to quickly enter any named symbols with an approach like typing "[ESC] alpha [ESC]" and an α appears (cf. http://reference.wolfram.com/language/tutorial/SpecialCharacters-MathematicalAndOtherNotation.html http://reference.wolfram.com/language/tutorial/SpecialCharac...). I think this is the right approach: Let the beautification to be done by the code viewers. The approach to enter named symbols probably stems from (La)TeX where one writes "$\alpha$" to get α and is typical to Computer Algebra Systems. For instance, SageMath as well as SymPy allow to define something like a=var("alpha") and render it like α.

MarkMMullin 9y ago
Been awhile since I used MM, but I do remember this - personally, I like using Fira with my code, but that's because there's a disgusting amount of math in it and it makes the reading a lot easier - your implicit separation between representation and presentation is spot on IMO

wodenokoto 9y ago

Do ligatures really act like one character? I've never encountered not being able to select only the f ro the i in a 'fi'-ligature, but I don't really use ligatures outside of word processing.

oneeyedpigeon 9y ago
Some of the ligatures in Fira Code are so radically different from the characters they're substituting, that single-character selection would be incredibly confusing. How would it behave for the characters on the final line of the sample, for example?

mikelward 9y ago

Premise: don't make => look like ⇒, because ⇒ is already a separate thing. Then later: check out this font I made where 0 looks like Ø.

jstewartmobile 9y ago

Somewhat off-topic, but the explosion Unicode glyphs can lead to problems more serious than aesthetics: Punycode exploit: https://www.xudongz.com/blog/2017/idn-phishing/ https://www.xudongz.com/blog/2017/idn-phishing/ Greek question mark: https://stackoverflow.com/questions/26965331/javascript-prank-joke https://stackoverflow.com/questions/26965331/javascript-pran... Shameless plug: https://github.com/BourgeoisBear/A-E-S-T-H-E-T-I-C https://github.com/BourgeoisBear/A-E-S-T-H-E-T-I-C

broxp 9y ago

Fortress (a dead JVM programming language by Guy Steele) had an interesting approach for special characters: https://de.wikipedia.org/wiki/Fortress_(Programmiersprache)#Darstellung_des_Quelltextes https://de.wikipedia.org/wiki/Fortress_(Programmiersprache)#...

fuzzygroup 9y ago

Ignoring the Unicode issues, I installed all of these, switched to the retina version of each in my editor and I found none of them any better than what I had been using (Menlo). I'm certain that YMMV but at least for me, there was no improvement (languages tested with were Ruby, and ERB formatted HTML).