News for hackers. Stuff that matters.
Re:Ligatures in programming fonts: hell no (2019) by 9dev on Tuesday December 21, 2021 @11:44AM (#29639127)
The author points out two problems, which both are ridiculously obscure edge cases: if there’s really a Unicode arrow in code you deal with, it likely won’t matter much if there’s an arrow or something closely resembling an arrow. The second point recommends getting rid of ligatures entirely just because they may, in some situations, do not display the right thing.

Both arguments ignore the 99.9999999999% of times ligatures do what they’re supposed to, and help me identify some symbols quicker. I’ll happily accept being confused once in a year about a strange-looking arrow in a debug log output, or from a weirdly rendered arrow in some ASCII art print.

People complain about weird stuff.

Re:Ligatures in programming fonts: hell no (2019) by eps on Tuesday December 21, 2021 @12:23PM (#29639619)
Why on Earth one would want in a character-oriented text (i.e. where every character matters separately) to have some of them collapsed into one is beyond me. Why not take it further and have IDE render all occurrences of "cat" with an emoji.
Re:Ligatures in programming fonts: hell no (2019) by detaro on Tuesday December 21, 2021 @12:31PM (#29639746)
Because in the cases ligatures are used most prominently, a "logical" character is made from multiple characters.
Re:Ligatures in programming fonts: hell no (2019) by 9dev on Wednesday December 22, 2021 @05:02AM (#29647416)
Nobody expects mathematicians to write all their formulae in ASCII either, they are allowed to use special markup to denote specific things. Why can't developers use more specific notation for displaying code? We use `==` for equality checks due to a limitation of typewriters, not because it's the only sensible way to do this. Give ligatures a chance for a single afternoon, and you'll see the value of purpose-specific glyphs. They aren't replaced by arbitrary hieroglyphs, but actually self-explanatory, helpful representations of the thing a bunch of characters are supposed to tell you.
Re:Ligatures in programming fonts: hell no (2019) by maweki on Wednesday December 22, 2021 @04:50AM (#29647333)
But the programming language is token-oriented.
Re:Ligatures in programming fonts: hell no (2019) by axelerator on Wednesday December 22, 2021 @11:00AM (#29651034)
But keyboards are not. Even if I’d be able to convince the maintainers of my favorite programming language to also accept some Unicode glyph as synonym to ‘==‘ how do I type it? Ligatures might not be ‘the right’ solution, but they are a highly efficient approximation. Also the cost of reversing the decision to use them is basically zero.
Re:Ligatures in programming fonts: hell no (2019) by maweki on Wednesday December 22, 2021 @05:09PM (#29656101)
That's what I said. To the programming language it's just a token and representing that with a single ligature is fine.

I replied to a comment, that the document is character-based and therefore ligatures are inherently wrong.

Re:Ligatures in programming fonts: hell no (2019) by karmakaze on Tuesday December 21, 2021 @11:59AM (#29639324)
The last place where you want to have to mentally apply any decoding rules is in "debug log output".
Re:Ligatures in programming fonts: hell no (2019) by 9dev on Tuesday December 21, 2021 @12:31PM (#29639748)
Are we still talking about the same thing..? Fira code has like 20 ligatures which enhance the rendering of arrows and equality signs. There’s no „decoding rules“ to apply. This is just way, way overblown. Are you really stumped and confused if there’s „=>“ vs. „⇒“ in a piece of text..?
Re:Ligatures in programming fonts: hell no (2019) by karmakaze on Tuesday December 21, 2021 @02:03PM (#29640778)
I never understood the justification though, beyond "it's pretty". When I see '<=' in a conditional, I see one symbol and attach its meaning. I've never needed to 'encode' that either.
Re:Ligatures in programming fonts: hell no (2019) by mattarm on Tuesday December 21, 2021 @01:41PM (#29640538)
I think the author failed to state the primary issue I have with ligatures: code listing using ligatures tend to be harder for me to read because the symbols are unfamiliar to me.

I first ran into this issue trying to learn Haskell, where some beginner websites used fonts like Fira Code in their listing. The "weird" operators I saw in the listings were unclear to me. In some cases I simply wasn't sure how to even reproduce the code in my editor. I think it is something I could grow used to and someday perhaps even enjoy, but as a beginner it was a barrier.

Re:Ligatures in programming fonts: hell no (2019) by WorldMaker on Tuesday December 21, 2021 @02:24PM (#29641041)
In most cases "copy and paste" still just work (unless the code listing was a screenshot, which is a bad idea anyway for teaching code) and you can learn it that way.

Also most of the lists of intentionally ligatured operators are pretty small and easy to find reference materials for. For instance Fira Code's big first chart in this section: https://github.com/tonsky/FiraCode#whats-in-the-box

Re:Ligatures in programming fonts: hell no (2019) by cbm-vic-20 on Tuesday December 21, 2021 @11:54AM (#29639255)
In the case of a "real Unicode arrow", I'd just as soon use a Unicode literal if the language supports it, like '\u2192'.
Re:Ligatures in programming fonts: hell no (2019) by erichurkman on Tuesday December 21, 2021 @12:00PM (#29639334)
Even better if your language supports it: use named escape sequences so you don't have to look it up. "\N{RIGHTWARDS ARROW}" vs "\u2192"
Re:Ligatures in programming fonts: hell no (2019) by hydroxideOH- on Tuesday December 21, 2021 @12:12PM (#29639481)
Or I could type -> and get on with my life.
Re:Ligatures in programming fonts: hell no (2019) by detaro on Tuesday December 21, 2021 @12:33PM (#29639763)
How does that give you the unicode character you need in the output? Or are you saying there is just never a reason to have those in strings?
Re:Ligatures in programming fonts: hell no (2019) by leephillips on Tuesday December 21, 2021 @12:39PM (#29639841)
If your computer is set up properly you just type <mod>-> to get →.
Re:Ligatures in programming fonts: hell no (2019) by mananaysiempre on Tuesday December 21, 2021 @01:02PM (#29640142)
Unfortunately, there’s a small amount of relatively common things you might want in literals that can be very confusing in monospace display: tabs, of course, but also all the other spaces (en, em, hair, etc., legitimately needed if you want your typography to be up to 18th-century standards and not argue about the “single vs double space” typewriter-age nonsense), hyphens and dashes and minuses (aka “why I’m still using -- and --- in my TeX code”), and so on.
Re:Ligatures in programming fonts: hell no (2019) by leephillips on Tuesday December 21, 2021 @02:47PM (#29641281)
I use the proper dashes, too, in prose (but when using TeX I use Unicode input these days). But even though some programming languages (such as Julia) would allow one to use the different dashes for different purposes, I don’t think that would be a good idea: they look too similar in, as you say, in monospace fonts.
Re:Ligatures in programming fonts: hell no (2019) by avgcorrection on Tuesday December 21, 2021 @01:43PM (#29640552)
I do use dashes and real (not pseudo-quotes, i.e. `"` and `'`) quotes in code comments but I only use the space symbol for whitespace.
Re:Ligatures in programming fonts: hell no (2019) by 3np on Tuesday December 21, 2021 @02:29PM (#29641091)
The author is also very clear about that they’re not talking about what you use in your local editor. It’s about when you make decisions impacting others. It’s a kind of accessibility.