[deleted]
Ligatures in programming fonts: hell no (2019)
51–60 of 201 posts
Re: Ligatures in programming fonts: hell no (2019)
#52> 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…
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?
I don't use ASCII-art often in source code, but when I do (or when I'm reading code from someone who has), I prefer if the characters align correctly.
Re: Ligatures in programming fonts: hell no (2019)
#53Just 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?
Modern languages do have unicode operators. See for example Julia[1] and Raku[2]
[1] https://docs.julialang.org/en/v1/manual/mathematical-operati...
Re: Ligatures in programming fonts: hell no (2019)
#54> Many of the programming ligatures shown above are easily confused with existing Unicode symbols.
That's just silly, the reason there are ligatures is precisely because all these programming languages are poorly designed not to allow using the proper ≠ instead !=, but then this is also why there is no ambiguity - your editor would highlight the real ≠ as a syntax error
Re: Ligatures in programming fonts: hell no (2019)
#55In practical terms, the big sin is using them in the web documentation of languages and libraries (which is public reference material and should reflect the reality of the syntax).
All this debate about individuals and their text editor setups is inconsequential compared to that.
Re: Ligatures in programming fonts: hell no (2019)
#56I don't mind the look of ligatures too much in most monospace fonts that have them. However, I use my editor and terminal emulator for a lot more than just editing source code in common programming languages. In every single ligature-supporting font I've tried, there are edge cases where glyphs are combined in a way that don't make sense in context, which is jarring enough to not be worth it for me.
Because they are intended to be a tool for typesetters to use in right scenarios - or in your case turn off in wrong ones. In text editors you can only go all in or not. It is not really intended for that.
> In text editors you can only go all in or not.
I don't think that needs to be the case. Text editors already do syntax highlighting, and if using treesitter they have accurate understanding of the syntax. So there isn't major blockers for applying ligatures selectively based on syntax.
Re: Ligatures in programming fonts: hell no (2019)
#57Just 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 <=
Because readability is more important than writeability.
Re: Ligatures in programming fonts: hell no (2019)
#58I've witness many a question after/during technical slides where the audience was confused by symbols. At a bare minimum, don't use ligatures in slides or blog posts or anything meant for a broad audience. Ideally, languages would support Unicode as well so you can mean what you say when you type—some folks will naturally prefer this to “keyboard-compatible” options and this should be fine (though ask many non-Anglop…
> slides or blog posts or anything meant for a broad audience. Or if you're screensharing while pairing, or if a coworker is looking over your shoulder when you're sharing something, or...
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.
Re: Ligatures in programming fonts: hell no (2019)
#59Just 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?
Modern languages do have unicode operators. See for example Julia[1] and Raku[2] [1] https://docs.julialang.org/en/v1/manual/mathematical-operati... [2] https://docs.raku.org/language/operators.html
Agda & PureScript support it, Haskell with the Unicode pragma too
Re: Ligatures in programming fonts: hell no (2019)
#60I gotta say I’m a little tired of using * for multiplication. It’s time for programming languages that use Unicode characters for operators, and let the editor replace != with the Unicode slashed equals character. No ligatures, just operators.
So now you have:
- A character harder to type
- The same potential confusion
- Code bases with both operators
Maybe programmers just need to know that ligatures exists. If you are programming in Java or Kotlin you know that intelliJ tend to use it.
Of course, if you have code, coping it to an ide with ligatures disabled will be rendered there old way just add it will use your preferred font or color highlighting schema.
So most of the problems are for images like slides.