Bugzilla – Bug 134037
xterm duplicating characters in output
Last modified: 2006-01-03 15:40:42 UTC
I experienced strange behavior of xterm. If typing in xterm, if any characters are behind cursor, they are duplicating. Also mc cannot be used (attaching screenshot). I don't experience such behavior in e.g. rxvt. My locale is: $ locale LANG=sk_SK.UTF-8 LC_CTYPE="sk_SK.UTF-8" LC_NUMERIC="sk_SK.UTF-8" LC_TIME="sk_SK.UTF-8" LC_COLLATE="sk_SK.UTF-8" LC_MONETARY="sk_SK.UTF-8" LC_MESSAGES="sk_SK.UTF-8" LC_PAPER="sk_SK.UTF-8" LC_NAME="sk_SK.UTF-8" LC_ADDRESS="sk_SK.UTF-8" LC_TELEPHONE="sk_SK.UTF-8" LC_MEASUREMENT="sk_SK.UTF-8" LC_IDENTIFICATION="sk_SK.UTF-8" LC_ALL=
Created attachment 57563 [details] screenshot
I can only reproduce this, when LC_ALL is set to sk_SK.UTF-8. Doesn't happen when LC_ALL is set to de_DE.UTF-8. Very strange ... I'm using xterm-207.
Also with cs_CZ.UTF-8 is everything OK. ;(
Thomas, any ideas? Can you reproduce it?
no - not outside mc. I've seen several comments about mc however regarding poor support for UTF-8. Perhaps this is a similar case. I'm running Debian testing, and see that for each case where there is a non-ASCII character, that mc does display that character, e.g., things from the Latin-1 set. Running in rxvt I also see related defects though not as many - probably due to differences in the font used (some fonts will have no glyph, or encode a zero-width glyph for a given position).
Vladimir, already heard about this problem? Vladimir is our mc maintainer.
I heard about it but now I found some time to look into it :) The difference of sk_SK.UTF-8 locale seems to be that a non-ascii character appears in bottom-right corner. It is a bug in slang library or mc. It prints an incomplete utf8 sequence followed by a control sequence. The first byte of the control sequence is lost and the rest is printed, causing scroll up. Other terminals handle this situation better. However, I cant reproduce the behavior without mc mentioned in the original report. Maybe it is another bug.
There may well be more than one bug. On Debian I have mc 4.6.1-1 built with slang2, and see incorrect placement after cells which have multibyte encoding (the Latin-1 I mentioned). slang2 has better UTF-8 support than the patched slang1, but I do not know how well mc has been integrated with it. Looking here, I do not see a package for slang2: http://suse.mirrors.tds.net/pub/opensuse/distribution/SL-10.0-OSS/inst-source/suse/src/ If SuSE's mc is built using slang1 plus the ad hoc UTF-8 patch, I would expect more (and different) bugs. It's hard to say whether differences in error-handling by other terminals are better or worse without a specific example (for instance a typescript file that one can analyze and replay on the different terminals).
We have mc with utf8 patches written by Jakub Jelinek from Red Hat and me. The patches were not accepted by upstream and debian package does not have them AFAIK. Slang2 was added to SL after 10.0. With patched slang1 this bug did not appear. In strace output the sequence looks like this: "Skon\304\33[24;79Hi\10" \304 is the first part of multibyte character \33 is the start of control sequence, which is ignored [24;79 is printed on the screen, you can see it on the last line on the screenshot.
The bug was in SLANG. Fixed.