Hi Eric, I was not ignoring this, but was trying to figure it out correctly.
My original hack (entirely within x.c) had some nasty side-effects while attempting to select or backspace (width isn't followed). My second approach (entirely within st.c) has the select problem fixed, but I'm still left with a width issue on backspace or even while arrow-keying (which does not affect Asian characters). More research and I figured out that is due to the mismatch between how the shell and my patch is handling the characters (and thus can't be solved). The x.c approach took advantage of the functions that find the glyph width of a font (f->width from xloadfont() ), and compare it to the width of the default font. If wider, track that in Fontcache, and force the runewidth to take that into account whenever that font was used. This approach is visually ugly during command line editing, but command line editing can still work, also the select functionality does not have access to the Fontcache to know that this was faked, so visually, selecting gets ugly, too. Past emoji, selection and the shell will put the cursor (and effective end of line) too far to the left, but this isn't too difficult to navigate once the user can see what is going on. This was my first approach, and of the two, this is probably the better bad solution. The st.c approach simply forces the ATTR_WIDE onto Glyph.mode when wcwidth() has already asserted a width of 1, and the Rune u is within the Emoji range. This makes output and selection work flawlessly, but editing is nearly impossible, because the controlling application cannot keep track of where the cursor actually is on the line (the application is expecting the cursor to be 1 position left for each emoji printed). This can lead to part of a prompt being eaten on re-draw, and on full backspace, it leaves part of the original text visible (but not there - according to the application). All this helps me understand why nobody else has bothered solving it so far, since the root of this issue is that wcwidth() is not returning 2 for emoji until last month -> https://lists.gnu.org/archive/html/info-gnu/2017-08/msg00000.html <- which is a glibc version very few have yet (and doesn't help me on macOS anyway). Anyway, neither approach is a fully working solution, so I don't want to post either as a patch suggestion. An update of glibc will just work (given a correct locale), and a recompile of everything that linked it statically. So, maybe it can only be properly fixed in a Gentoo install. For my own copy of st, I have removed all of this, and find that I am running a patch that will not to print out anything that isn't acceptable to the locale, (!iswprint(u)) near the top of tputc(), and I'll just learn to live with emoji overwriting each-other when they are printed without actual spaces between them. Thank you, Gary Allen Vollink On Thu, Sep 14, 2017 at 4:53 PM, Eric Pruitt <[email protected]> wrote: > On Thu, Sep 14, 2017 at 01:51:26PM -0700, Eric Pruitt wrote: >> On Thu, Sep 14, 2017 at 12:01:42PM -0400, Gary Allen Vollink wrote: >> > 3) I'm not proud of this, but it works reliably. I wrote a nasty hack >> > that force-fixes the width/overlap problem with Emoji (and some other >> > odd font-substitution problems). I know that this is 'fixed' in >> > glibc's most recent release - following UNICODE recent guidance that >> > all Emoji are double-width, but it isn't fixed on macOS (Emoji without >> > spaces don't even work right in Terminal.app). Anyway, it is >> > something I could throw together as a diff - sub 40 lines. I don't >> > have a handle on what the protocol is for sharing such a thing. >> >> Make a patch. Attach the patch to an email or submit it to the wiki >> (https://git.suckless.org/sites/tree/st.suckless.org/patches). >> Instructions for submitting patches are provided on >> https://suckless.org/hacking. > > Also, please post the patch to the mailing list either way. Even if it > doesn't get accepted into mainline or the wiki, I would like to see it > since I've had some problems with emoji width on Linux that I haven't > spent time investigating yet. > > Eric >
