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

151–160 of 201 posts

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

#151

Post by Macha »

hakre wrote: post #133
Macha wrote: post #122

Earlier quoted context omitted.

UTF-8's using only characters from the ASCII subset is just ASCII, this was kind of the point of UTF-8 at inception.

Yes, exactly, and Unicode has more encodings than UTF-8 so stating it explicitly makes clear which encoding of Unicode that is. Writing only ASCII would not be relaying on Unicode, but on ASCII only. IMHO a bit shortsighted today.

Using UTF-8 but only the ASCII bits, and using ASCII are the exact same activity, however. I don't see how the first is any different to the latter, other than which document you look up to tell you that 00110000 is "0". The difference between an "ASCII subset of UTF-8" parser and ASCII parser is whether the error message on encountering a high bit set to 1 is "Invalid character" or "Character not in permitted ranges".

If your point is that your program should use Unicode internally, this is already true for most programming languages but is independent of your input, plenty of languages routinely converting UTF-16 to UTF-8 to work with Linux or the web when they use UTF-16 internally, or UTF-8 to UTF-16 to work with Windows when they use UTF-8 internally. But I'd argue if you've done that work already, what harm is there in allowing your users to type € or á or 風?

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

#152

Post by jeroenhd »

rcarmo wrote: post #12

I don’t agree. I find that ligatures in Fira Code make it rather more pleasant to read contrived pieces of JavaScript (I’m looking at you, “===“). But to each his own.

=== and !== are definitely the main reason I tried out ligatures in the first place.

The author has hidden their point all the way at the end of the article, though. They're mostly talking about sharing code, such as in screenshots, printed works, slides, etc.

People who don't know fonts commonly use ligatures (plenty of fonts that mess with fi or other commonly custom kerned characters) so they don't realise I'm not actually using the ≠ or ≥ characters in my code.

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

#153

Post by klyrs »

Joeri wrote: post #98
FridgeSeal wrote: post #19

> 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.

I once came across a true monospace ligature font. It was the absolute worst. Especially when combining letters like ff, fi, ffi...

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

#154

Post by jeroenhd »

eloisius wrote: post #45
rswail wrote: 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 <=

> Most modern languages already use Unicode for variable names and such

I've never actually thought about using comparative characters, but that actually makes a lot of sense. I think people will disagree if you use them, but there's no reason why you wouldn't be able to call a variable x≥y≤z…

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

#155

Post by mananaysiempre »

ketzu wrote: post #39

> if you’re preparing your code for others to read—whether on screen or on paper—skip the ligatures. The article should have led with this. Instead this main caveat is buried in a paragraph, where it is preceded by, what boils down to, "do what you want, but you will recognize its wrong someday." Of course people will focus on that part and on the most prevalent use of ligatures in programming: In their own local edi…

> The tangent in (1) on how they contradict unicode could have been skipped as well

Not only because confusables already exist, but also because (as I said[1] the previous time this was posted) covering all ligatures used in all typographical styles is very much a non-goal of Unicode. The official position is that the font shaping layer[2] sits atop Unicode’s semantic representation and is free to ligate, spindle, or mutilate it for display however it prefers (at least for Latin, Greek, and Cyrillic it’s a preference; other scripts can’t be rendered at all without doing it, such as Arabic—barring the legacy presentational forms—or Burmese[3]).

The only reason Unicode even has those ligatures is that some IBM encodings (which were more presentational in nature) encoded them, and the IBM employees who wrote a large part of the early standard (based on the decades of i18n experience they had at that point) wanted roundtripping.

[1] https://news.ycombinator.com/item?id=29639966

[2] https://github.com/n8willis/opentype-shaping-documents

[3] https://r12a.github.io/scripts/mymr/my.html#compositeV

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

#156

Post by _V_ »

jeroenhd wrote: post #150
_V_ wrote: post #69

A page that does not load any content with disabled JavaScript: hell no I mean am I the only one that is browsing with completely disabled JS by default? :-D More and more sites don't load anything withnout a JS and I'm not talking about advanced apps like Microsoft Office online...

Even worse, the content is right there in the HTML. If you hit the reader mode button, it renders just fine without executing any code. I wonder why you would self sabotage your website like that.

Yeah, I don't really get it. Why screw up your own page deliberately so that it cannot be normally accessed? I mean the amount of actual effort and man-hours put into making something worse is beyond me

And I can only imagine, how screwed up internet must be for disabled people that need some kind of reader etc...

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

#157

Post by bombcar »

pc86 wrote: post #149

It's interesting that the author is complaining about the readability/usability of ligatures while their site has horrible linking usability. Tiny red superscript circle with zero indication of what text is linking and what size the clickable area of the link is.

As is painfully common on typesetters’ work when done “online” as they seem unable to bend the rules for ease of use in a digital world.

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

#159

Post by bombcar »

rswail wrote: 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?

APL says hi.

life ← {⊃1 ⍵ ∨.∧ 3 4 = +/ +⌿ ¯1 0 1 ∘.⊖ ¯1 0 1 ⌽¨ ⊂⍵}

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

#160

Post by wwarner »

I changed my mind on this one. As long as the text editor is not introducing its own transformations (as wysiwig editors do), then it's alright with me for programmers to use as many unicode characters as they want. In other words, as long as I'm confident that the function I'm reading is exactly what was committed and what will be compiled, it's fine with me that programmers expand the charset.
Post reply on HN