Ligatures in programming fonts: hell no (2019) • Hacker News Board

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

#131

Post by kps » Sat, May 13, 2023, 2:06 PM UTC

sundarurfriend wrote: post #80

thxg wrote: post #37

Ligatures are an interesting contrast to Julia programmers' habit of using actual (non-Latin) Unicode characters in their code. It seemed to me that the use of Greek letters and symbols is actively encouraged in the Julia documentation. I think they advise using editors that allow inputting special characters through their LaTeX equivalent (but source files are then saved to disk with the Unicode characters). I am no…

A lot of Julia folks use the JuliaMono font, which has a minimal set of ligatures: https://juliamono.netlify.app/#contextual_alternates (just above this segment, they mention this very article as something they agree with). I personally don't like any ligatures, especially when people use them in presentations to public like the article mentions. Confusion between operators is rare, but possible, for eg. when using C…

Whatever font you prefer in the terminal, Julia Mono is an excellent fallback due to its high symbol coverage.

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

#132

Post by f1shy » Sat, May 13, 2023, 2:09 PM UTC

George83728 wrote: post #100

hakre wrote: post #28

Earlier quoted context omitted.

Just was wondering if today anyone is still using them, so I guess that does not need to be asked. All right, oh my captain, keep the indents and spacing tight on the monospace and sail along! Btw., anyone still using monospaced fonts in their editors?

The only people I've ever seen or heard of using proportional fonts for programming were utterly clueless freshmen newbs who mistook MS Word for a text editor...

Caution: Stroustrup uses proportional fonts for snippets in the book

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

#133

Post by hakre » Sat, May 13, 2023, 2:11 PM UTC

Macha wrote: post #122

hakre wrote: post #89

Earlier quoted context omitted.

For portable code, use UTF-8 only, and only the part in ASCII. This also helps to distinguish digits from alphas etc. Unicode is a different code. (and as I learned today, Julia code might be exclusive here)

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.

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

#134

Post by toastal » Sat, May 13, 2023, 2:13 PM UTC

conradludgate wrote: post #95

toastal wrote: post #88

Earlier quoted context omitted.

$ nix-shell -p tmate --command tmate Now they have it for a one-off

error: nix-shell command not found

Oh you need something more modern, np

    $ nix shell nixpkgs#tmate --command tmate

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

#135

Post by gibspaulding » Sat, May 13, 2023, 2:14 PM UTC

This reminds me of a struggle I've run into lately. Can anyone recommend a convenient way to identify an individual Unicode character or string of characters?

Ideally I'd like to be able to e.g. highlight one of these weird ligatures, or a whitespace that I want to identify, or an emoji my font doesn't support and select something like "identity this character" from the context menu to see what symbol or series of symbols I'm actually looking at.

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

#136

Post by kps » Sat, May 13, 2023, 2:15 PM UTC

chrismorgan wrote: post #116

nottorp wrote: post #110

Earlier quoted context omitted.

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

> (But I really wish Space was split into at least two keys. It’s so stupidly large.)

If you can stand the tiny distant Return, get a Japanese keyboard.

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

#137

Post by s-lambert » Sat, May 13, 2023, 2:17 PM UTC

throwawaymaths wrote: post #83

toastal wrote: post #58

Earlier quoted context omitted.

TBH, remote pairing in my experience is best done with a tool like upterm or tmate so the user can bring their own terminal toolbox (fonts, colors, settings) and it saves a lot of bandwidth too while remaining crisp, especially when text becomes compressed and hard to read.

Well not all your coworkers will have that especially if you're not a place that does pairing all the time but just as one-offs.

You could alternatively use VSCode Live Share which is pretty similar.

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

#138

Post by kps » Sat, May 13, 2023, 2:20 PM UTC

samatman wrote: post #68

pwdisswordfishc wrote: post #43

Earlier quoted context omitted.

I can’t wait for a programming language that considers the strings ">=" and "≥" to be equal.

The Raku language does so already, and isn't the only one. Unclear if it will ever be ubiquitous, but I'm betting on widespread in a couple decades.

That's awful. Can you have "<=" ≡ "≤" and "<=" ≡ "⇐" but "≤" ≢ "⇐"?

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

#139

Post by mberning » Sat, May 13, 2023, 2:28 PM UTC

That www one is a true abomination.

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

#140

Post by alpaca128 » Sat, May 13, 2023, 2:34 PM UTC

chrisweekly wrote: post #106

alpaca128 wrote: post #72

> The problem? Many of the programming ligatures shown above are easily confused with existing Unicode symbols. How so? It's either a ligature or a syntax error: weird unicode symbols can't be valid operators and operator ligatures cannot be valid identifiers. The exception would be string literals, though that situation would be quite rare - probably less common than ambiguity due to different but similar-looking un…

I agree the "confused w Unicode symbols" arg is pretty weak. As for "people don't mind [tabs] at all", some people mind very much and consider them pollution. If you mean _some_ people don't mind tabs, ie you're highlighting that tabs vs spaces is a bigger deal than ligatures, I concur. The logical reason to prefer spaces is that the choice is not "spaces vs tabs", it's "spaces vs (tabs and spaces)", and that mix of…

> If you mean _some_ people don't mind tabs, ie you're highlighting that tabs vs spaces is a bigger deal than ligatures, I concur.

Yes, contrary to spaces/tabs ligatures only affect how it is displayed on screen, letting everyone choose how they want it without any drawback or inconsistency. Which is why I find the other argument in the link a bit unconvincing too - most code isn't shared in static screenshots, though I'll agree when it comes to books.