Red Hat Bugzilla – Bug 143818
Talk doesn't handle input in UTF-8
Last modified: 2013-07-02 19:04:38 EDT
Description of problem:
Entering non-ASCII data creates various display problems.
Version-Release number of selected component (if applicable):
On second thought, it doesn't handle even iso-8859-2.
Please disregard comment #1. It was Christmas and I was
really paying attention to the talk going on rather than
talk behavior... ISO 8859-2 seems to work now.
Created attachment 109517 [details]
Created attachment 109518 [details]
The attached patch (just sent upstream) adds handling of multi-byte character
encodings (most importantly UTF-8) and double-width characters (for east-Asian
languages) to the talk client.
- Separating s_columnpos (colun number) and s_typebufpos (strlen (s_typebuf))
- Adding code to find the last (possibly incomplete due to the byte-at-a-time
input) character in s_typebuf, just before the terminating \0
- Decoding the multibyte character in display_addch () [if possible, e.g.
it is not incomplete], getting its width, and using it for deciding whether
to wrap the line
- Moving all bytes of an incomplete multibyte character to the next line when
wrapping it to the next line
- Adding dorefresh () calls before every display_addch () because it needs
the correct s_columnpos
- Using locale-specific data to determine which characters should be ^-escaped.
Created attachment 109519 [details]
The necessary spec changes, together with some cleanups.
Hi, thanks for the patch. Any idea why we need position independent
code for talk on s390, s390x?
We need it always (for PIE); it's just that -fpic puts
a limit on data size on some architectures and you have
to use -fPIC for those; apparently it is s390* here.
(I haven't tested whether -fPIC is really needed, I just
assume this was the reason.)
I modified these things:
- Removed redundant #define _GNU_SOURCE from the beginning of display.c
since we use -D_GNU_SOURCE in CFLAGS. (added in spec)
- Removed redundant variable 'y' introduced by your patch. There's no
need to use getyx() as we have getcurx() when we're only interested in
the x position.
Created attachment 109547 [details]
The modified patch