Ligatures in Programming Fonts: Hell No • Hacker News Board

Re: Ligatures in Programming Fonts: Hell No

#61

Post by jon-wood » Thu, May 02, 2019, 11:41 AM UTC

C1sc0cat wrote: post #56

jake-low wrote: post #10

Used 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…

No I do not what some ide to start fucking about with code and introducing god only knows strange edge cases. And I use profanity (Engineering language) for good reasons here can you imagine any other engineering discipline allowing this to happen - oh yes the CAD system added a ligature in the bridge design blueprints !!

Ligatures in your editor don't change the underlying, code they just change the presentation of that code when you're viewing it. While a ligature supporting font may show you ≥, the underlying source file still contains the distinct characters >=

Re: Ligatures in Programming Fonts: Hell No

#62

Post by Cthulhu_ » Thu, May 02, 2019, 11:46 AM UTC

jake-low wrote: post #10

Used 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…

My counter-argument: eslint and tools like that will warn or error when you use `==` when you should be using `===`, up to the point where `==` is considered a code smell (JS's 'loose' comparison has been the target of a lot of brouhaha)

Re: Ligatures in Programming Fonts: Hell No

#63

Post by diegoperini » Thu, May 02, 2019, 11:53 AM UTC

sklivvz1971 wrote: post #45

>Bottom line: this isn’t a matter of taste. It is, quite unequivocally, a matter of taste. Please don't pass your personal, unsubstantiated opinions as a matter of fact. :-)

100% agree. No editor comes with such font used as default. If a user wants to add fancy ligatures, she has to set it up by herself. It is very unlikely for such person to forget she is using ligatures in the middle of coding. Also, text editors put the caret to a proper position if the selected text breaks a ligature in the middle.

I personally see no problem using Fira Code aside from 10 seconds long brain hiccups every once in while (once per year, maybe rarer). I've been using it since 2015, on multiple editors including Xcode, Android Studio, iTerm2, Sublime Text, Atom, VS Mac, VS Code and IntelliJ. I can't even remember which one of these still doesn't support the proper rendering of ligatures, and yet no issues for me so far.

Re: Ligatures in Programming Fonts: Hell No

#64

Post by ufo » Thu, May 02, 2019, 11:55 AM UTC

billpg wrote: post #40

Is Personally, I'd love a keyboard that had a ≤ key and a programming language that recognized that symbol.

On Linux I love using the "Compose" key to type these unusual characters. It works better mnemonically than having special keys for everything.

One language that uses unicode symbols liberally is Agda. Since it is a proof assistant, being able to use mathematical symbols helps a lot. They even remap the backspace key on Emacs to act as a sort of Compose key for typing all the symbols.

Re: Ligatures in Programming Fonts: Hell No

#65

Post by gwenzek » Thu, May 02, 2019, 11:56 AM UTC

wbond wrote: post #44

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

Came here to say this ST handles ligatures very sensibly

Re: Ligatures in Programming Fonts: Hell No

#66

Post by ken » Thu, May 02, 2019, 12:06 PM UTC

I've never used ligatures like this, and I have no horse in this race, but I don't find these arguments compelling.

1. By this reasoning, Unicode contradicts itself. There's lots of codepoints that I can't visually distinguish from one another, even when printed without ligatures. If the quality of visual uniqueness is important, better stick to printable ASCII.

2. Every syntax-highlighter I've ever used, for any language more complex than a Lisp, has been wrong, occasionally. Every IDE "find text" feature finds useless results, occasionally, from lack of context, too. Again, if perfection is your threshold for use, you're going to have to throw out half your editor.

If you want to go all Marie Kondo on your toolchain (like Chuck Moore has been doing for decades), that's neat, but that doesn't sound like what he's advocating here.

> If you don’t believe me, try it for 10 or 15 years.

Every time a programmer tells me this, and I ask around, I find that the population is split. Seriously, you don't believe me that emacs is 1000 times better than vi? Try it for a few years.

Re: Ligatures in Programming Fonts: Hell No

#67

Post by ilikehurdles » Thu, May 02, 2019, 12:42 PM UTC

sklivvz1971 wrote: post #45

>Bottom line: this isn’t a matter of taste. It is, quite unequivocally, a matter of taste. Please don't pass your personal, unsubstantiated opinions as a matter of fact. :-)

Exactly. My ligatures affect no other reader’s presentation. It is absolutely personal taste. What an absurd rant.

Re: Ligatures in Programming Fonts: Hell No

#68

Post by ilikehurdles » Thu, May 02, 2019, 12:48 PM UTC

cseelus wrote: post #49

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.

I’m on your side with ligatures. Pry them from my cold dead hands. But given that the author is a font designer he probably has had many heated discussions on the matter and that’s probably why he cares so much.

Re: Ligatures in Programming Fonts: Hell No

#69

Post by WkndTriathlete » Thu, May 02, 2019, 12:48 PM UTC

I'm unconvinced, because as far as I'm concerned ligatures are a viewing enhancement and have nothing to do with writing the code. Maybe there are (extreme) edge cases where I might accidentally confuse a Unicode code point with a ligature, but since those symbols are (relatively) difficult to access on most keyboards to begin with, I don't think any practical difficulty would ever present itself.

I've often thought that smarter IDEs should be able to recognize the language and display code in the user's preferred style with better use of screen space. For instance, a Java class could be displayed with the class signature in a fixed header; enclosed methods could be displayed starting at the left, instead of indented; stacks of annotations could be replaced by a gutter icon with a hover/click to show/expand/close; methods could be grouped and ordered by particular criteria; etc., all while the underlying source file remains intact.

Re: Ligatures in Programming Fonts: Hell No

#70

Post by dmitriid » Thu, May 02, 2019, 12:55 PM UTC

LeonidasXIV wrote: post #57

dmitriid wrote: post #20

Fira 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…

> Unfortunately, there's no good way to have a font have sets of ligatures per . But there is, see Iosevkas ligature sets which switch different ligatures on and off. The editor can just opt-in which one to use. There might not be sufficient editor support for it but you can work around it by generating different versions of it as default and then configure your editor to use that font. Not elegant but workable.

That's what I meant when I wrote that sentence: either the font doesn't have those sets, or the editors can't enable them, or there's no easy way to support different fonts for different languages, or...

It's not limited to just programming. Font fallbacks for multi-language texts (for example, English and Russian; that is, Latin and Cyrillic) in most (all?) mediums are usually horrible, and usually revert to whatever the OS provides.