5 ms·
Unicode in code might be what pushes people to consider variable-width font. Just look at the simple arrow in a text editor (hopefully the text filter on this w
by avgcorrection 3y ago
Unicode in code might be what pushes people to consider variable-width font. Just look at the simple arrow in a text editor (hopefully the text filter on this website thinks this symbol is OK): → (U+2192 RIGHTWARDS ARROW). It’s tiny. And I notice that the author uses plain `->`. You do need at least an “em” width for that kind of symbol.
But I wouldn’t want a normal variable-width font where colons are tiny and at-signs are gigantic. I read a programming email list in my regular webclient and it can be quite tiring. :)
- proc0 3y agoIt seems we're really close to making language specific fonts. Haskell would certainly be a prime candidate for this.
- int_19h 3y agoFonts with "programming ligatures" have been a thing for some time now, and those ligatures tend to favor certain language families in practice.
- proc0 3y agoRight, but they are general purpose monospace fonts. I would think something like a Haskell font or Python font would go beyond that and provide tailored designs for those languages. I wouldn't be surprised if those exist, but haven't seen them.
- NikkiA 3y agoAPL would say 'hi' using both its custom EBCIDIC code page(s) and its dedicated selectric ball.
- pxc 3y agoIs Hasklig not already such a font? https://github.com/i-tu/Hasklig https://github.com/i-tu/Hasklig
- todd8 3y agoAnother problem with using unicode in code is the handling of Unicode equivalence, compatibility, and normalization[1]. The same glyph can be produced in multiple ways. How is the reader, vim or emacs, and the compiler supposed to handle these cases? [1] https://en.wikipedia.org/wiki/Unicode_equivalence https://en.wikipedia.org/wiki/Unicode_equivalence
- PhilipRoman 3y agoI suppose making more characters double-width could solve this problem with minimal changes needed to terminal-based software.