Bug 143818 - Talk doesn't handle input in UTF-8
Talk doesn't handle input in UTF-8
Product: Fedora
Classification: Fedora
Component: talk (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jindrich Novy
Depends On:
  Show dependency treegraph
Reported: 2004-12-28 17:42 EST by Miloslav Trmač
Modified: 2013-07-02 19:04 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-10 09:57:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Internationalize talk (5.13 KB, patch)
2005-01-08 14:18 EST, Miloslav Trmač
no flags Details | Diff
Internationalize talk (5.13 KB, patch)
2005-01-08 14:21 EST, Miloslav Trmač
no flags Details | Diff
The necessary spec changes, together with some cleanups. (1.48 KB, patch)
2005-01-08 14:23 EST, Miloslav Trmač
no flags Details | Diff
The modified patch (5.27 KB, patch)
2005-01-10 04:35 EST, Jindrich Novy
no flags Details | Diff

  None (edit)
Description Miloslav Trmač 2004-12-28 17:42:36 EST
Description of problem:
Entering non-ASCII data creates various display problems.

Version-Release number of selected component (if applicable):
Comment 1 Miloslav Trmač 2004-12-28 17:43:14 EST
On second thought, it doesn't handle even iso-8859-2.
Comment 2 Miloslav Trmač 2005-01-03 15:07:56 EST
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.
Comment 3 Miloslav Trmač 2005-01-08 14:18:46 EST
Created attachment 109517 [details]
Internationalize talk
Comment 4 Miloslav Trmač 2005-01-08 14:21:43 EST
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.
Comment 5 Miloslav Trmač 2005-01-08 14:23:27 EST
Created attachment 109519 [details]
The necessary spec changes, together with some cleanups.
Comment 6 Jindrich Novy 2005-01-10 03:22:16 EST
Hi, thanks for the patch. Any idea why we need position independent
code for talk on s390, s390x?
Comment 7 Miloslav Trmač 2005-01-10 04:08:23 EST
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.)
Comment 8 Jindrich Novy 2005-01-10 04:34:11 EST
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.
Comment 9 Jindrich Novy 2005-01-10 04:35:01 EST
Created attachment 109547 [details]
The modified patch

Note You need to log in before you can comment on or make changes to this bug.