Ligatures in programming fonts(tinyletter.com) |
Ligatures in programming fonts(tinyletter.com) |
"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
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...
I disagree with this. The problem with lots of programming tools is the difficulty of judging which options are the best for your use case, before you have the experience of using them for a long time. So there is a real temptation to just go along with what everyone else seems to be doing; since they presumably know the benefits. There doesn't even have to be a real trend; it's enough when there's one in your perception.
I have certainly done quite a lot of trend-following myself. I have used relative line numbering in vim ever since I started using it, simply because the first person I ever saw using vim had that option active. Later, when I found myself doing mental arithmetic to get absolute line numbers, I was simply too lazy to make the switch. I have actually only just now gotten around to changing my config.
So someone who is thinking about switching to a ligatured code font might benefit from an article like this, if it turns out that the issues raised would be too annoying for them. If they don't think those will be a problem, however, they can just go right ahead and make the switch.
But every classification the highlighter does do must be accurate, or it's a buggy highlighter.
And FWIW, it's certainly possible to write a syntax highlighter that does parse the whole program. You'd normally find this in an IDE rather than a programmer's text editor. For example, writing Swift in Xcode, everything gets precisely highlighted, to the point where references to real types are highlighted whereas references to unknown types (e.g. typos) aren't. It's not practical to do this outside of IDEs, which is why most syntax highlighting only tries to highlight that which it can unambiguously determine.
I really wanted to learn APL after seeing Conway's Life implemented[1] as one expression with no loops or temporary variables (using ⌹). Then I realized I would never remember how to type all of the {di,tri}graphs.
and both Dyalog (free now for non-commercial use) and GNU APL (via Emacs) have secondary input methods until you get comfortable.
It going to be hard to express the intent when programming if you never write that expression onto non-volatile storage.
> break them up into multiple characters so they can be edited
Several different methods exist for editing Unicode. (e.g. [1])
> As they are under control of the font, editors don't need special support either.
That's exactly the problem. Most editors used for programming already understand the full syntax for many programming languages, while font-ligatures only match short character sequences. As the article mention, this will incorrectly replace some things that happen to share the same sequence of characters. There are also problems[2] in editors with storage or drawing boundaries in the middle of a ligature. Mapping the correct characters to a replacement glyph is a lot easier when you understand the surrounding grammar.
[1] https://docs.perl6.org/language/unicode_entry
[2] The bug tracker for FiraCode has several reports of
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.
He's doing something really interesting with the funding model of practicaltypography, that I believe should be praised.
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.
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.
While I don't agree with much of this blog post, I certainly think the author has put in enough work to have their work taken seriously in this particular domain, and generally seems like a pretty interesting person.
1. http://practicaltypography.com/equity.html