If it is consistency and perfection everywhere you are looking to find, software engineering in general might not be the best job for you.
Ligatures in Programming Fonts: Hell No
31–40 of 89 posts
Re: Ligatures in Programming Fonts: Hell No
#32> 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 bit more proficient in German - but ligatures do have semantic meaning. At least in German, they should never cross a word boundary in composite words, for example Kaufleute (merchants) is Kauf-leute (buy-people), so you would not use a "fl" ligature. There are actually words where this resolves an ambiguity, I think. Historically, this is the reason sometimes ss and sometimes ß is used. I always assumed there were similar subtle rules in English.
As to the "ligatures" in programming fonts - I would not call them such, problem solved. Rather, they are substitutions in the tradition of APL or vim conceal mode - to get mathematical notation with a standard keyboard.
Re: Ligatures in Programming Fonts: Hell No
#33Ligatures always confused me...
Re: Ligatures in Programming Fonts: Hell No
#34Re: Ligatures in Programming Fonts: Hell No
#35Usually, 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…
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, and this is a normal part of typesetting for several languages.
Unicode breaks Unicode, it's not meant to be consistent, only compatible.
Re: Ligatures in Programming Fonts: Hell No
#36Usually, 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…
Re: Ligatures in Programming Fonts: Hell No
#37Usually, 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…
Re: Ligatures in Programming Fonts: Hell No
#38Used judiciously, ligatures can help make code more readable, not less. Consider JavaScript's == and ===, and their inverses != and !==. I personally find them difficult to visually distinguish on occasion (especially the negative forms). Fira Code [0] replaces them with two-bar and three-bar equals signs (something like =, ≠, ≡, and ≢, only wider; see the link for a screenshot). I personally find these easier to dis…
Don't forget people read whole words, so they most likely don't spend much time on "==" recognition than they would with "equivalent". And with text completion, token length is an irrelevant metric on productivity as well.
Any non literal symbol used in code is an incentive to use more of them and turn code bases into harder to maintain "smart" obfuscated trick stacks.
On an historical perspective, how much people using "=" know where it comes from (nothing is more equal than two parallel lines), compared to how many people are able to make a good guess of the etymology of "equivalent" (same value)? Add to this observation that in the mid-time with the raise of non-euclidian geometry and topology the former insight is far less relevant nowaday.
Re: Ligatures in Programming Fonts: Hell No
#39Fira Code's main problem is that it tries to be a font for all programming languages which results in some weird behaviours here and there. Unfortunately, there's no good way to have a font have sets of ligatures per . That said, however, the article fails to provide a compelling argument against ligatures. 1. Fonts have nothing to do with Unicode. It's exactly the font's job to provide any glyphs or ligatures it wan…
If your IDE (or text editor) can highlight and indent languages differently then it can certainly switch font or toggle a font property to select a ligature variant set.