3 ms·

Another reason for using almost monospace: international languages. Many indic languages simply don't have good monospace fonts. It's not easy to design. They s

Another reason for using almost monospace: international languages. Many indic languages simply don't have good monospace fonts. It's not easy to design. They stick out in code, as a result. But I've always wondered if allowing three or four different widths would help. We could still align text if (narrow) spaces were the smallest unit, and other widths were repeated multiples of that. This makes me think it's doable.

DenisM 4y ago
Neat idea. This would probably vindicate the “tabs” people of the tabs/spaces debate.
adastra22 4y ago
Same goes for East Asian languages which are monospaced, but square. If you mix English (or code) with Chinese/Japanese/Korean, you get a mixed-width mess.
- layer8 4y ago
  It’s well-defined, at least in the terminal: the east-asian characters are simply double the normal width. There’s a Unicode property to decide which is which: https://www.unicode.org/reports/tr11-2/ https://www.unicode.org/reports/tr11-2/
  - adastra22 4y ago
    I was saying something else. If you mix latin text and Chinese text in a monospaced font, the character boundaries no longer line up.
    - layer8 4y ago
      They still line up (when rendered with correct double-width), the east-asian characters just take up two “slots”, as if they were two normal characters. I don’t know if you see a problem with that, or if you’re talking about renderers and/or applications that don’t correctly handle this double-width logic. My point is that if handled correctly, e.g. in terminals, there is no problem with that, as long as the application is double-width aware. For example I use Mutt as a mail reader in a terminal, with Vim as an editor, and mixed latin and east-asian characters work fine with them and line up on the terminal grid.
      - adastra22 4y ago
        I don't think I've ever seen a double-width font outside of an actual terminal emulator though. It's really frustrating that the fonts used by all IDE's and graphical emacs/gvim/vcode seems have this mixed script spacing issue.

DenisM 4y ago

Neat idea. This would probably vindicate the “tabs” people of the tabs/spaces debate.

adastra22 4y ago

Same goes for East Asian languages which are monospaced, but square. If you mix English (or code) with Chinese/Japanese/Korean, you get a mixed-width mess.

layer8 4y ago
It’s well-defined, at least in the terminal: the east-asian characters are simply double the normal width. There’s a Unicode property to decide which is which: https://www.unicode.org/reports/tr11-2/ https://www.unicode.org/reports/tr11-2/
- adastra22 4y ago
  I was saying something else. If you mix latin text and Chinese text in a monospaced font, the character boundaries no longer line up.
  - layer8 4y ago
    They still line up (when rendered with correct double-width), the east-asian characters just take up two “slots”, as if they were two normal characters. I don’t know if you see a problem with that, or if you’re talking about renderers and/or applications that don’t correctly handle this double-width logic. My point is that if handled correctly, e.g. in terminals, there is no problem with that, as long as the application is double-width aware. For example I use Mutt as a mail reader in a terminal, with Vim as an editor, and mixed latin and east-asian characters work fine with them and line up on the terminal grid.
    - adastra22 4y ago
      I don't think I've ever seen a double-width font outside of an actual terminal emulator though. It's really frustrating that the fonts used by all IDE's and graphical emacs/gvim/vcode seems have this mixed script spacing issue.