5 ms·

Yes, looking like Alacritty is far from supporting it as well [1]. Not that it usually bothers me and I really do not care for ligature-based coding fonts, but

by ninjin 6y ago

Yes, looking like Alacritty is far from supporting it as well [1]. Not that it usually bothers me and I really do not care for ligature-based coding fonts, but it can pop up in e-mails and filenames for things like umlauts. [1]: https://github.com/alacritty/alacritty/issues/50 https://github.com/alacritty/alacritty/issues/50

imhoguy 6y ago
Umlauts? How come one needs ligatures for umlauts as they are independent characters with own Unicode or even old ASCII set codes[0]. [0] https://resources.german.lsa.umich.edu/schreiben/unicode/ https://resources.german.lsa.umich.edu/schreiben/unicode/
- ninjin 6y ago
  You do not need ligatures for umlauts, but that does not stop the odd software (or maybe user?) here and there refusing to do it the “sensible way”.
- hibbelig 6y ago
  I believe that Unicode has multiple representations for Latin characters with diacritics: ä can be represented as a single character, but it can also be represented as two characters, “a”, plus “add two dots to the previous character”. You can convert between these forms.
square_usual 6y ago
No knock on people who spend their time working on Free Software, but I genuinely don't understand why discussion threads turn sour so quickly when it comes to terminal emulators and ligatures. Both in the linked thread and in the case of libvte [1] (a terminal emulator widget used in tons of popular emulators) the maintainers seem to be aggressively against ligatures. It's a shame because I can't find a single terminal emulator on Linux that is as usable as iTerm2, and not having ligatures is the biggest knock against most of them IMO. 1: https://bugzilla.gnome.org/show_bug.cgi?id=584160 https://bugzilla.gnome.org/show_bug.cgi?id=584160
- thristian 6y ago
  Most terminal emulators date back to a time when one byte of input occupied one character-cell on-screen. Since Unicode arrived with combining characters, terminals have adapted to N bytes of input occupying one character-cell, or under special circumstances (Chinese characters, emoji) two character-cells. Proper ligature support requires terminals to support N bytes of input mapping to M character cells... and unlike the N:1 or N:2 cases, the N:M case doesn't allow a hard-coded list of how many cells an input string covers, it varies from font to font. And that risks software designed for one font breaking in a terminal that uses a different font, if it has a different set of ligatures, or the ligatures are different sizes.
  - wezfurlong 6y ago
    Yeah, this stuff is hard. The approach used in wezterm is to use unicode graphemes for cells, and use the unicode width of the grapheme to decide whether a given cell is double-width. Ligatures are handled at rendering time, partly because the terminal emulation and model layer doesn't know about fonts (it can run "headless" in a multiplexer where there are no fonts), and partly because the shaper library doesn't output information about cells but rather about which glyphs to render in which positions--that information doesn't easily map to the terminal cell model. For extra pain, some font designers have ligatured sequences that map to a single glyph that may be several cells wide, while others use alternative glyph fragments for each component of the ligature, and others may emit two blank glyphs, followed by a triple wide glyph with a negative x offset of almost two blank glyphs in width. It's difficult to map this information to cells.
  - sime2009 6y ago
    The problem actually existed before Unicode appeared. Terminals which supported Chinese, Japanese, or Korean characters have had to deal with 2 cell wide glyphs, even for text encodings which use 1 byte per glyph. If you see the term "full width" character in old terminal related specs and documents, they are talking about 2 cell CJK glyphs/characters.
- sime2009 6y ago
  If "usable as iTerm2" means the terminal actually aims to have features, then you can try my project Extraterm ( https://extraterm.org/ https://extraterm.org/ ). It supports ligatures and more.

by ninjin 6y ago

imhoguy 6y ago

Umlauts? How come one needs ligatures for umlauts as they are independent characters with own Unicode or even old ASCII set codes[0]. [0] https://resources.german.lsa.umich.edu/schreiben/unicode/ https://resources.german.lsa.umich.edu/schreiben/unicode/

ninjin 6y ago
You do not need ligatures for umlauts, but that does not stop the odd software (or maybe user?) here and there refusing to do it the “sensible way”.
hibbelig 6y ago
I believe that Unicode has multiple representations for Latin characters with diacritics: ä can be represented as a single character, but it can also be represented as two characters, “a”, plus “add two dots to the previous character”. You can convert between these forms.

square_usual 6y ago

No knock on people who spend their time working on Free Software, but I genuinely don't understand why discussion threads turn sour so quickly when it comes to terminal emulators and ligatures. Both in the linked thread and in the case of libvte [1] (a terminal emulator widget used in tons of popular emulators) the maintainers seem to be aggressively against ligatures. It's a shame because I can't find a single terminal emulator on Linux that is as usable as iTerm2, and not having ligatures is the biggest knock against most of them IMO. 1: https://bugzilla.gnome.org/show_bug.cgi?id=584160 https://bugzilla.gnome.org/show_bug.cgi?id=584160

thristian 6y ago
Most terminal emulators date back to a time when one byte of input occupied one character-cell on-screen. Since Unicode arrived with combining characters, terminals have adapted to N bytes of input occupying one character-cell, or under special circumstances (Chinese characters, emoji) two character-cells. Proper ligature support requires terminals to support N bytes of input mapping to M character cells... and unlike the N:1 or N:2 cases, the N:M case doesn't allow a hard-coded list of how many cells an input string covers, it varies from font to font. And that risks software designed for one font breaking in a terminal that uses a different font, if it has a different set of ligatures, or the ligatures are different sizes.
- wezfurlong 6y ago
  Yeah, this stuff is hard. The approach used in wezterm is to use unicode graphemes for cells, and use the unicode width of the grapheme to decide whether a given cell is double-width. Ligatures are handled at rendering time, partly because the terminal emulation and model layer doesn't know about fonts (it can run "headless" in a multiplexer where there are no fonts), and partly because the shaper library doesn't output information about cells but rather about which glyphs to render in which positions--that information doesn't easily map to the terminal cell model. For extra pain, some font designers have ligatured sequences that map to a single glyph that may be several cells wide, while others use alternative glyph fragments for each component of the ligature, and others may emit two blank glyphs, followed by a triple wide glyph with a negative x offset of almost two blank glyphs in width. It's difficult to map this information to cells.
- sime2009 6y ago
  The problem actually existed before Unicode appeared. Terminals which supported Chinese, Japanese, or Korean characters have had to deal with 2 cell wide glyphs, even for text encodings which use 1 byte per glyph. If you see the term "full width" character in old terminal related specs and documents, they are talking about 2 cell CJK glyphs/characters.
sime2009 6y ago
If "usable as iTerm2" means the terminal actually aims to have features, then you can try my project Extraterm ( https://extraterm.org/ https://extraterm.org/ ). It supports ligatures and more.