Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ligatures in Programming Fonts: Hell No

practicaltypography.com

Post reply on HN
Print view View original

41–50 of 89 posts

Re: Ligatures in Programming Fonts: Hell No

#41

Post by lawn »

I usually agree with the author, but not really here.

> They contradict Unicode

So what?

The ligatures are only supposed to look good in my editor, with my config, in the programming language I use and for my eyes only. Nothing else matters.

> They’re guaranteed to be wrong sometimes

See previous point.

As long as it's good enough for my purposes in the context I use the font, it doesn't matter if it breaks some edge case that makes the author upset.

> Bottom line: this isn’t a matter of taste.

It is a matter of context, which the author completely misses.

And yes, it's also a matter of taste. Everything design related is in parts taste.

Re: Ligatures in Programming Fonts: Hell No

#42

Post by pjc50 »

captainmuon wrote: post #32

Usually, the author is spot-on with his recommendations and I really enjoy reading his website. So I was a bit surprised about this: > When we’re using a serifed text font in ordinary body text, we don’t have the same considerations. An fi ligature always means f followed by i. In that case, ligature substitution that ignores context doesn’t change the meaning. Maybe this is different in English typography - I'm a bi…

Perhaps, but the automatic ligature substitution doesn't know that, and indeed in Times "Kauflete" is rendered with a ligature. Probably because native English speakers aren't used to accent or ligature rules.

Anyway, I too agree with the author; if you want ≥ to appear on your screen, it should be in the source text as the UTF-8 bytes for U+2265 and the tooling should understand it. Programming is too fragile to allow misunderstandings between the bytes that are interpreted by the machine and the glyphs that the programmer understands to be inserted.

Going much further back, there are the C trigraphs '??!' etc, for those whose character sets don't contain '|'. I've not seen editors attempt to automatically show those as the substitute characters either.

(Oh, and if you want to be unpopular, try entering unicode characters in your language variable identifiers or git commit messages and see how much tooling you can break...)

Re: Ligatures in Programming Fonts: Hell No

#43

Post by kapep »

cotelletta wrote: post #35
captainmuon wrote: post #32

Usually, the author is spot-on with his recommendations and I really enjoy reading his website. So I was a bit surprised about this: > When we’re using a serifed text font in ordinary body text, we don’t have the same considerations. An fi ligature always means f followed by i. In that case, ligature substitution that ignores context doesn’t change the meaning. Maybe this is different in English typography - I'm a bi…

The whole point of ligatures is that they are visually subtle enough that you don't consciously notice them, while removing distracting collisions of adjacent glyphs. The German rule seems entirely pointless and counterproductive. That said, OP is wrong that ligatures would "break Unicode". The only ligatures that are directly encoded exist for historical reasons. Fonts can and should make contextual alternatives, an…

> The German rule seems entirely pointless and counterproductive.

The rule provides visual hints for how to pronounce words. I think that is way more useful than slightly increasing the readability by joining glyphs without context.

Re: Ligatures in Programming Fonts: Hell No

#44

Post by wbond »

> The problem is that ligature substitution is “dumb” in the sense that it only considers whether certain characters appear in a certain order. It’s not aware of the semantic context.

At least in Sublime Text this is not true. We tokenize the text according to the rules in the syntax definition and then pass characters to be shaped, but respecting token boundaries.

In fact, we’ve fielded a number of bug reports about ligatures not working, and it is almost always that the syntax definition was tokenizing the = and the > as separate tokens.

We also made the decision to only pass runs of symbols to the text shaping engine, as opposed to runs of alphanumeric characters. This prevents ligatures like fl that are usually not useful in a monospace layout such as a text editor. There are also options to control the OpenType features for ligature fine tuning.

Re: Ligatures in Programming Fonts: Hell No

#46

Post by Freak_NL »

pjc50 wrote: post #42
captainmuon wrote: post #32

Usually, the author is spot-on with his recommendations and I really enjoy reading his website. So I was a bit surprised about this: > When we’re using a serifed text font in ordinary body text, we don’t have the same considerations. An fi ligature always means f followed by i. In that case, ligature substitution that ignores context doesn’t change the meaning. Maybe this is different in English typography - I'm a bi…

Perhaps, but the automatic ligature substitution doesn't know that, and indeed in Times "Kauflete" is rendered with a ligature. Probably because native English speakers aren't used to accent or ligature rules. Anyway, I too agree with the author; if you want ≥ to appear on your screen, it should be in the source text as the UTF-8 bytes for U+2265 and the tooling should understand it. Programming is too fragile to all…

Why would using non-ASCII characters (I assume that is what you mean by Unicode characters) in a git commit message break anything sensible? It's meant to be human readable text, and defaults to UTF-8 (although you can use legacy encodings if you really must).

Any git hook processing stuff would just look for stuff it does understand (like '([Cc]lose(s)?|[Ff]ix(es)?) #[0-9]+' or something similar) and ignore the rest.

Scores of developers use non-ASCII characters as part of their native language every day in git commit messages, and even non-BMP Unicode characters like emoji work just fine.

Re: Ligatures in Programming Fonts: Hell No

#47

Post by g105b »

I see font ligatures in the same light as tab characters. They are configurable in the editor and don't affect the source code, but enhance visual clarity while not forcing programming languages to now have to support custom operators such as "≥".

Re: Ligatures in Programming Fonts: Hell No

#48

Post by zeitg3ist »

Stratoscope wrote: post #24
gnicholas wrote: post #12

I thought programming fonts are typically monospaced, which means collisions (which create the need for ligatures) aren't much of an issue. I agree that ligatures aren't good in programming, but it just seems the need wouldn't be that great. Or am I missing something?

I always code in a proportional font, but even there the typical operator character sequences like == don't collide or run together. OTOH, perhaps because I use a proportional font, I would be curious to try one with operator ligatures. The interesting thing is that a ligature for !== wouldn't have to be three characters in width to preserve alignment, it could actually be the normal ≢ glyph. This suggests an experim…

Could you share a screenshot of your editor with Trebuchet? I would never think of it (or any other proportional font) as an adequate font for coding, so I’m pretty curious to see what it looks like.

Re: Ligatures in Programming Fonts: Hell No

#49

Post by cseelus »

Why do folks that don‘t want to use them even care?

It’s not that when they are used, different code is produced. As with the editors color scheme, it’s just a personal choice everyone can live out within the privacy of his or her editor.

Personally I find it nice to represent single logical tokens like => or === with just a single character.

Post reply on HN