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

Ligatures in programming fonts: hell no (2019)

practicaltypography.com

Post reply on HN
Print view View original

111–120 of 201 posts

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

#111

Post by mpweiher »

cabirum wrote: post #2

Much ado about nothing. It's a matter of personal taste. An actual ≠ has a low chance to sneak into the source code, even lower chance to somehow type it by hand. Either way, it would be a syntax error highlighted by any editor. I'd like my code to look nice and I accept the risks.

> An actual ≠ has a low chance to sneak into the source code,

Hmm...my programming language supports ≠ directly ...

> even lower chance to somehow type it by hand.

... and my keyboard lets me type it (almost) directly, via Alt-=.

I think the author is spot on in that the current state is not the correct end-state, though given path-dependencies it is understandable how we got here.

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

#112

Post by amake »

hakre wrote: post #87
loup-vaillant wrote: post #84

Earlier quoted context omitted.

> Btw., anyone still using monospaced fonts in their editors? Tell me you've never programmed without telling me you've never programmed… Almost all code editors and IDEs in current use are set with a monospaced font by default, and the overwhelming majority of programmers keep it that way.

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)

Tell me you've never actually used programming ligatures without telling me etc. etc.

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

#114

Post by omnimus »

zokier wrote: post #56
omnimus wrote: post #36

Earlier quoted context omitted.

Because they are intended to be a tool for typesetters to use in right scenarios - or in your case turn off in wrong ones. In text editors you can only go all in or not. It is not really intended for that.

> In text editors you can only go all in or not. I don't think that needs to be the case. Text editors already do syntax highlighting, and if using treesitter they have accurate understanding of the syntax. So there isn't major blockers for applying ligatures selectively based on syntax.

It might be possible in code because it's more constrained enviroment but well it hasn't been solved in general typesetting. The rules are very hard to hardcode because it is subjective and often requires broad context (like understanding line above or what you do with names). Thats why it has been always done by humans if you want good results. And its not like smart people havent tried (like Knuth for example).

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

#115

Post by wffurr »

veidr wrote: post #74

I initially had this same reaction. Well, perhaps less stridently assembled, but my initial take on it was the same: that ligatures for coding fonts were objectively dumb. But, I was wrong. In several years of using them now, there has never been even one case of the theoretical "mistaking a different glyph that looks similar to the ligature" or "mistaking a ligature character sequence for a single character". It's n…

My takeaway from this article is that I want to go try Fira Code now.

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

#116

Post by chrismorgan »

nottorp wrote: post #110
chrismorgan wrote: post #99

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.

> Fun but I tend to type code fast.

When you’re used to it, and given the comparative infrequency of the characters you use it for, it’s not much of a burden—just ~three key presses instead of one.

> Really dont need an extra modifier key.

Note that Compose isn’t a modifier key in the most common understanding of the word: you don’t hold it down while you press the others (which would certainly be awful for its ergonomics), but you press keys in sequence.

> Not to mention there isnt one on your regular keyboard.

On my current laptop I map RAlt to Compose. On my previous laptop, it was RMenu. There’s always at least one key there that you literally never need to use, and I find the ergonomics for thumb usage very comfortable. (But I really wish Space was split into at least two keys. It’s so stupidly large.)

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

#117

Post by tptacek »

TonyStr wrote: post #44
grzm wrote: post #25

Earlier quoted context omitted.

> 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. Later in the submission, Butterick addresses this directly, and doesn't disagree: > “What do you mean, it’s not a mat­ter of taste? I like us­ing lig­a­tures when I code.” Great! In so many ways, I don’t care what you do in pri­vate. Al­though I pre­dict you will even­tu­ally burn your­self…

Later, in the "by the way" section after the article. After an article that in no way suggests it's talking about printed and shared code exclusively. After paragraphs such as this > Bottom line: this isn’t a matter of taste. In programming code, every character in the file has a special semantic role to play. Therefore, any kind of “prettifying” that makes one character look like another—including ligatures—leads to…

It is an attack on using ligatures in code. It's not hiding that. That's the point of the article.

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

#118

Post by miniBill »

wffurr wrote: post #115
veidr wrote: post #74

I initially had this same reaction. Well, perhaps less stridently assembled, but my initial take on it was the same: that ligatures for coding fonts were objectively dumb. But, I was wrong. In several years of using them now, there has never been even one case of the theoretical "mistaking a different glyph that looks similar to the ligature" or "mistaking a ligature character sequence for a single character". It's n…

My takeaway from this article is that I want to go try Fira Code now.

Do it! It's great!

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

#119

Post by veidr »

scotty79 wrote: post #104
veidr wrote: post #74

I initially had this same reaction. Well, perhaps less stridently assembled, but my initial take on it was the same: that ligatures for coding fonts were objectively dumb. But, I was wrong. In several years of using them now, there has never been even one case of the theoretical "mistaking a different glyph that looks similar to the ligature" or "mistaking a ligature character sequence for a single character". It's n…

> Allman brace style If only that could be as easily configurable in IDE as liatures.

Indeed. I think we’ve gotten a lot closer in the past few years though (after wanting this for almost 20 years without progress).

Rust’s language service (optionally) adds phantom code to several modern editors, showing inferred types in the editor, that aren’t really part of the source code.

That is very nearly the same thing...

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

#120

Post by kps »

hinkley wrote: post #9

I gotta say I’m a little tired of using * for multiplication. It’s time for programming languages that use Unicode characters for operators, and let the editor replace != with the Unicode slashed equals character. No ligatures, just operators.

> I gotta say I’m a little tired of using * for multiplication.

U+2062 is the obvious solution.

Post reply on HN