Live data from Hacker News

Ligatures in programming fonts: hell no (2019)

practicaltypography.com

181–190 of 201 posts

Re: Ligatures in programming fonts: hell no (2019)

#181
post #179

Earlier quoted context omitted.

Yes, and you can also shoot, strangulate, or set an idea on fire. Metaphorically speaking. But metaphor is imprecision and unnecessary colour. Be clear and precise. Use specific language. This is admittedly prescriptive usage, but I am prescribing this antidote for an overheated era, full of overwrought language.

This arbitrary restriction on language seems doubleplus ungood.

Wait till you read Strunk & White

Re: Ligatures in programming fonts: hell no (2019)

#182
post #98

> Whereas ligatures are going the opposite direction: making distinct characters appear to be others. Yes. On my computer. In my editor. That I am using…because I like ligatures, because they make my code easier to read. For me. Use of ligatures on my setup does not force anyone else to use them? They’re not “viral” like a language feature. “Oh but what if the >= Unicode symbol ends up in your source code and you don…

Ligatures in a fixed width programming context still take up the full width of the separate characters, so a unicode symbol of the ligature has a different width from the ligature itself, and this is immediately obvious.

On the other hand, this is one aspect that makes those ligatures typographically jarring to me. It replaces one compromise with another bad compromise.

Re: Ligatures in programming fonts: hell no (2019)

#183
post #3

Earlier quoted context omitted.

It's probably fine for you reading your code. It's not impossible it causes others reading your code some confusion when they render it with ligatures or receive eg pdf of it in ligatures, distinct from how it looks when they edit it. Minor issue mostly. I tend to "no", but for no very good reason: Aesthetically they're lovely.

Other people reading your code... on your laptop, using your editor? Because on anyone else's computer it's going to be based on their personal viewing preferences. Setting your tab spacing size too large will also make your code unreadable. But only on your computer.

Screen sharing is a thing.

Re: Ligatures in programming fonts: hell no (2019)

#184
post #42

Just reading all of this (I haven't used ligatures when coding), but the confusion between a ligature of >= and the Unicode ≥ (U+2265) could be handled by the language parser accepting either to mean "greater than or equal to". Would moving beyond ASCII be that much of a stretch for modern languages?

This is a problem insofar as when searching for “>=“ or “≥“ you will only match one of them, and you are prone to getting a mix of both in your codebase. Ligatures effectively create a non-canonical rendering, and then adding a non-canonical alternate encoding doesn’t really improve the situation.

A proper way would arguably be for the programming language to only understand “≥“, and for editors to provide support for entering such characters (or the user can configure a system-wide Compose key or similar). IMO we should work on standardizing keyboard input for those symbols instead of de-standardizing code display via ligatures.

Re: Ligatures in programming fonts: hell no (2019)

#186

Earlier quoted context omitted.

A Compose key is the best general-purpose way. For example: • ≥: Compose > = • ≠: Compose / = You can define your own sequences too, if you want. I like to type exactly what I mean, including curly quotes and dashes and narrow no-break spaces and emoji and so on, but often didn’t like the default mappings (if there were any). As an example, I use this for curly quotes (look at the keys’ locations on the keyboard to u…

Fun but I tend to type code fast . Really dont need an extra modifier key. Not to mention there isnt one on your regular keyboard.

It’s not a modifier key, it’s a separate key you type before, like an escape character. I use the Caps Lock key for it.

For very common sequences that you always want to have mapped you can use a tool like AHK so that you don’t have to press Compose before.

The beauty of Compose though is that it works everywhere, and that it gives you access to a much larger character set in a very mnemonic way. For example, “ga” can map to “α” (“greek a”), “gb” to “β”, and so on. “2-” can map to “–“ (en dash), “3-“ to “—“ (em dash), “3.” to “…”, “c,” to “ç”, “i,” to “į”, “e,“ to “ę”, and so on. There are a lot of patterns that apply to a whole range of characters, it’s a bit like how commands combine in Vim.

Re: Ligatures in programming fonts: hell no (2019)

#187
post #42

Just reading all of this (I haven't used ligatures when coding), but the confusion between a ligature of >= and the Unicode ≥ (U+2265) could be handled by the language parser accepting either to mean "greater than or equal to". Would moving beyond ASCII be that much of a stretch for modern languages?

Most modern languages already use Unicode for variable names and such. But why would you want to type a Unicode lte/gte character? I’m sure it’s not that hard on a Mac keyboard, but can’t be easier than <=

You could make “>“ a dead character that combines with “=“ to “≥”. Then it’s just as easy to type (at the price of a verbatim “>=“ becoming slightly harder to type).

Re: Ligatures in programming fonts: hell no (2019)

#188
post #87

Earlier quoted context omitted.

Which brings us back to the point of ligatures which are combining so make a single of what is a double or triple and hence no monospace any longer. No judgement if that is good or bad or at all. Just a reminder that it ain't monospace any longer. > Your code is still monospaced in all the ways that matter. Just it ain't monospace any longer. (reminder)

All coding fonts that do this ensure that the ligatures still fit the same width as the characters that are being combined.

Nope, the one a co-worker uses combines >= into the space of 1 character.

Re: Ligatures in programming fonts: hell no (2019)

#189
post #67
post #10

I have absolutely no idea how many people might share print screens of their code, and how often some beast looking at these images might, because of that, find a way to discover how to type a similar looking symbol in unicode, enter it in their editor, and compile it without error, therefore introducing a subtle bug. Luckily I rarely share my code through pdf, but mostly through git. Therefore, that hypothetical bea…

You don't kill good design just because it can be misused, you improve tooling design to deal with misuse For example, the text spoofer issue can be resolved in the text tools, like having variables with different names can be colored differently (this coloring scheme is better than having color just denote variable even without spoofing as it allows you to catch typos easily) Also you can have zero-width spaces high…

> having variables with different names can be colored differently

This, too, is entirely personal preference. I've tried it and found it resulted in too many colors for my brain to assign individual meanings to, and then I couldn't even benefit from syntax highlighting anymore because those colors also blended into the rainbow of text.

Re: Ligatures in programming fonts: hell no (2019)

#190
post #131

Earlier quoted context omitted.

A lot of Julia folks use the JuliaMono font, which has a minimal set of ligatures: https://juliamono.netlify.app/#contextual_alternates (just above this segment, they mention this very article as something they agree with). I personally don't like any ligatures, especially when people use them in presentations to public like the article mentions. Confusion between operators is rare, but possible, for eg. when using C…

Whatever font you prefer in the terminal, Julia Mono is an excellent fallback due to its high symbol coverage.

You know what, I'd tried JuliaMono in my editor (gVim) and for some reason didn't like it there, but making it my console font makes my terminal look so much better. Thanks for the recommendation.
Post reply on HN