Description of problem: Entering non-ASCII data creates various display problems. Version-Release number of selected component (if applicable): talk-0.17-23
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] Internationalize talk
Created attachment 109518 [details] Internationalize talk 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. This involves: - 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