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).
Ligatures in programming fonts
81–87 of 87 posts
Re: Ligatures in programming fonts
#82The 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 ): "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 i…
I'm a little miffed that the blog author doesn't have a good understanding on how Unicode and OpenType cooperates. Your first point is a great example of that.
As for your second point, I think what I outline here solves most of the problems that the other commenters are arguing about.
Actually, such features can be somewhat properly implemented in OpenType. You can tag these alternate glyphs as stylistic sets, with each stylistic set supporting so-and-so family of programming languages. Then, by default, an unaware editor would not perform the ligature substitution.
However, proper support will still require some standard awareness from the editor through some standard API, so that it selects the right stylistic set for the right text (e.g. comments v. code).
Emacs already does a form of character substitution through prettify; I use it all the time with LaTeX, and found it delightful to work with. It substitutes commands that stand for mathematical symbols with those mathematical symbols defined in Unicode. The limitation of this is that some of the features illustrated in Fira Code such as the prettified Markdown header don't have a corresponding Unicode code point, and thus necessarily has to be implemented as a ligature in a stylistic set.
A final note on the productivity of substituting input characters with more semantically representative symbols for display: when done well, it is not obtrusive and shouldn't hinder productivity. After all, the Chinese and Japanese do this all the time with a more clunky system (IME) in their digital input, and they get by well enough with it.
Re: Ligatures in programming fonts
#83Earlier quoted context omitted.
Sure, and the Dane has to figure out how to write down ø, taking them out of their flow — until they learn to apply the correct tool for the job.
I'm not sure if you're sarcastic or not. However, I'm Dutch, and we have similar tokens. Nobody minds if you write Danish code, but if you like contributors, it is asking a lot of them to change their editor or tools to collaborate with you. I hope you didn't mean your collaborators have to adjust to you like that.
Not at all; the point is that a Dane isn't actually taken out of their flow to type ø in Danish, because they're using a suitable keyboard layout. Likewise a programmer need not be taken out of their flow to type (a→t ≠ 0) or a ← b ∧ ¬c or (2=0+.=T∅.|T)/T←ιN.
Re: Ligatures in programming fonts
#84I 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 >' 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, ...
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…
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.
Re: Ligatures in programming fonts
#85Interestingly, 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.htm... ) or ∞ indicating Infinity ( http://reference.wolfram.com/language/ref/Infinity.html ). As Mathematica inherit…
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
Re: Ligatures in programming fonts
#86Ligatures are for personal usage only. If you are doing presentation to me and use ligatures, I will judge you.
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 :-)
Re: Ligatures in programming fonts
#87I 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 loo…
> 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.