After upgrading xterm from 285 to 297 I found incorrect displaying of box drawing characters with make menuconfig, alsamixer and other ncurses-based programs. Downgrading xterm back to 285 has resolved the problem. All cases of incorrect displaying are related to box drawing characters and, possibly, other non-ASCII characters. Screenshots attached. Reproducible: Always Steps to Reproduce: 1. in xterm: `cd /usr/bin/linux && make menuconfig' 2. enter in "General Setup", then enter in "Local version" or 1. `/usr/bin/alsamixer' 2. press F6 3. press Esc Actual Results: Screenshots 1 and 2 On screenshot 1: there are shown excess characters from previous window On screenshot 2: there is no colour graphs; there are shown excess characters from previous window Expected Results: Screenshots 3 and 4 Usually I launch xterm with LANG ru_RU.UTF-8. For this bug, I tested it with LANG en_US.UTF-8 and got the same results. The used font is: XTerm*font: -*-andale mono-medium-r-normal-*-15-*-*-*-*-*-iso10646-1
Created attachment 362890 [details] Screenshot 1, make menuconfig in xterm-297
Created attachment 362892 [details] Screenshot 2, alsamixer in xterm-297
Created attachment 362894 [details] Screenshot 3, make menuconfig in xterm-285
Created attachment 362896 [details] Screenshot 4, alsamixer in xterm-285
Created attachment 362898 [details] emerge --info
Sorry. Errata: Steps to Reproduce: 1. in xterm: `cd /usr/bin/linux && make menuconfig' -> Steps to Reproduce: 1. in xterm: `cd /usr/src/linux && make menuconfig'
Assignee: dickey@radix.net did not match anything
radix.net's gone (dickey@his.com is still my primary email)
Just looking at the screenshots, I don't see the cause. It would help to see exactly what characters are sent, e.g., using "script" to capture a typescript file for the two cases.
Created attachment 362906 [details] typescript alsamixer in xterm-285
Created attachment 362908 [details] typescript make menuconfig in xterm-285
Created attachment 362910 [details] typescript alsamixer in xterm-297
Created attachment 362912 [details] typescript make menuconfig in xterm-297
Just a note: I have noticed the change of default USE flags for xterm-297: openpty. Not related?
I wouldn't expect openpty to be related (though without knowing the cause, that's an educated guess only). I'll look at the typescripts (thanks)
The typescripts replay either way for me - using Mac OS X. Looking at the screenshots (menuconfig is simpler), I see three issues: a) at the top, some of the background is not cleared b) on the lower-left, some of the cells have inconsistent widths c) overall, some of the text is either misplaced or not cleared. The alsamixer screenshots I agree show a problem in the middle where the line-drawing is, but taking the menuconfig screenshots into account I'm seeing it as a problem in not completing erasures. The inconsistent cell-widths sounds like a problem reported in Debian which was said to be an X server problem: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640464 Why xterm #285 and xterm #297 might behave different isn't apparent to me, but if this is relevant, then learning more about it might suggest a workaround.
This could be an EXA issue which is only exposed by the newer xterm. Can you try booting with nouveau.noaccel=1 kernel parameter, or use xf86-video-modesetting instead of nouveau?
(In reply to Chí-Thanh Christopher Nguyễn from comment #17) > This could be an EXA issue which is only exposed by the newer xterm. Can you > try booting with nouveau.noaccel=1 kernel parameter, or use > xf86-video-modesetting instead of nouveau? I have tried nouveau.noaccel=1. Noticed broken conky... And all the same behaviour of xterm-297.
Well... going from #285 to #297 is about a year's worth of changes. Is it feasible to test the versions in between, and for instance narrow the difference down to one version of xterm?
Bisection? Why not?
Please could you give me instructions - where to download, etc. Something similar to http://wiki.winehq.org/RegressionTesting .
I'm not certain, but am assuming that you can modify the ebuild script. All of the tarballs for xterm source are here: ftp://invisible-island.net/xterm/ http://isbd.net/ted/xterm/
Also, this shows some possibilities: http://packages.gentoo.org/package/x11-terms/xterm
Okay, I'll try.
thanks
Results of testing are unexpected. All versions of xterm from 292 to 296 worked well for me from the image folder (/var/tmp/portage/x11-terms/xterm-<version>/image/). I didn't qmerge them. (292 and 293 were compiled according to its own ebuilds; others, which don't have own ebuilds - according to renamed 293 ebuilds) Then I compiled 297 and launched it from the image folder, without qmerging, too. And it worked well for me too. Then I understood that the problem could be in my file ~/XTerm. It didn't take long to determine that all bugs described here disappear after deleting one line from ~/XTerm: XTerm*font: -*-andale mono-medium-r-normal-*-15-*-*-*-*-*-iso10646-1 How didn't I guess to try this before :) At one moment I was really close to this ;) But isn't it a bug anyway? What's the reason of... aversion to this font?
I'm guessing again. But recall my comment about the cells which have inconsistent widths (you can see this in attachment 362890 [details]). Supposing that the andale-mono font has been converted from some other format, and that the metrics (data which says how wide each glyph is) is inaccurate (for instance, due to scaling, etc). xterm sees one of two cases: a) the font says some characters have different widths than the font's nominal width. b) the font says that all of the characters have the same width. If the font is wrong, then xterm will place one cell after another, not noticing that the position is wrong. This can (I think) affect the clearing operations since xterm does those based on its assumption.
So, it's (rather) a bug in andale mono.
Yes, I think so. I've run into problems with a few fonts (one of the changes in #297 was to attempt a better compromise working around a problem in the Terminus font encoded for 10646).
In principle, xterm could be altered to assume that the font metrics are incorrect (and write each character separately rather than relying on the string-writing functions in Xlib). I _think_ that would make it slower, however. If this is not a rare occurrence, then I should investigate doing that.
Interesting. Thank you.
no problem (report bugs)
The problem described here is different from 491334, because the line-drawing characters are unambiguously single-width.
please retry with 331 version, it seems to work ok for me (with alsamixer for example)
