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 <eric.pruitt_AT_gmail.com> 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
>
Received on Sat Sep 16 2017 - 08:33:46 CEST