On Sun, Sep 17, 2017 at 3:30 PM, Janne Heß <janneh...@gmail.com> wrote: > What I also found is that several unicode combine characters aren't > detected properly. For example, a female black police officer (rarely > used, but exists) is rendered as three different emojis (color, gender > and police officer). I assume st doesn't does this processing, but which > library does it so I can report a bug?
Agree that combiners probably should be supported if they could be. Both terminals and command-line tools (all of them) rely heavily on wcwidth() to do the right thing (and all seem to have collectively decided to revert to width 1 if wcwidth() returns -1). On my system, wcwidth() can't deal with combiners at all (wcwidth accepts an unsigned long). (that is, it can't deal with more than 4 bytes, 'st' could fake it, but then the underlying program (shell, mux, screen, etc) would still break. That is, 'st' could reserve the space, but when a shell-line edit is ready to happen, the shell gets confused and editing/cursor is off by one for each emoji that appears. This because the shell itself isn't expecting a double-width character. On output alone (no edit) it sure looks nice. Once editing is required, one quickly tires of this mismatch. > > On 09/17/2017 09:03 PM, ACE wrote: >> On 09/17, Janne Heß wrote: >>> It looks like the crash is caused by the font. >>> Switching from noto emoji to emoji one fixes the crash. I'll try looking >>> into the grid escaping bug... >> Similarly, if a character has a mis-match between wcwidth() and the font's actual size for it (VERY common in Emoji), but also true for some non-emoji characters, the overlap is going to just happen. The character breaks out of grid, and over paints part or all of the following character's grid-space. With the font Noto Sans Symbols, this happens with Place of Interest:⌘(not actually an emoji). It would be possible to clear out a new glyph's grid prior to painting it, but doing so slows things down everywhere for the occasional misbehaving over-wide glyph (and in some cases looks uglier than just letting the overlap remain). I noted in a previous thread [ https://lists.suckless.org/dev/1709/32306.html ] that wcwidth was recently fixed/updated in Linux's glibc: [ https://lists.gnu.org/archive/html/info-gnu/2017-08/msg00000.html ]. Ultimately, this (and recompiling everything that links it statically) is the RIGHT way to fix all of these issues. For the future person finding this via web search: Graphical Web Browsers do not have this issue because they are not fixed grid systems. They are asking for the width of EACH individual glyph, and painting it with the appropriate space. They are also not sharing with underlying programs that expect a grid system or expect to be able to rely on wcwidth() to know what is shown on the screen. Of course, web browsers also have the additional functionality to deal with full-color emoji fonts - which seems way beyond scope of any terminal built to have less suck. Thank you, Gary Allen
