"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.
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.
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.
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.
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.
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.
I use vim, so I find it great to have them in normal mode, and then disabled (set conceal =0) on entering insert mode.
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.
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.
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.
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.
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-p...
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.
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.
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.
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.
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.
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?
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).
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.
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.
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.
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/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/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 α.
Punycode exploit: https://www.xudongz.com/blog/2017/idn-phishing/
Greek question mark: https://stackoverflow.com/questions/26965331/javascript-pran...
Shameless plug: https://github.com/BourgeoisBear/A-E-S-T-H-E-T-I-C
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.
Then later: check out this font I made where 0 looks like Ø.
https://de.wikipedia.org/wiki/Fortress_(Programmiersprache)#...
But in a monospace font? No. No. No. no. No.
Epicly bad plan to use something like that to display code
