Description of problem: This problem is probably easier described with a screenshot (I'll attach one later). I've seen this happen in both gnome-terminal and on the console, so I don't think its terminal specific. Reading a mail and then advancing to the next leaves bits of the old mail readable. The old mail sticks around if I 'q' to go back to the folder index too, making it very unreadable. Version-Release number of selected component (if applicable): As shipped with FC3t1, but has been around during FC2 as well. How reproducible: 100% on certain emails.
Created attachment 101820 [details] email showing bits of previous email in headers.
The underlying library in this case is slang-utf8, not ncurses. (The application shown is mutt). This bug should be reassigned to the slang-utf8 package.
AFAIK, this is because of the xterm/gnome/etc terminfo 'fun'.
can you tell me if the problem occurs with other settings for TERM (xterm, xterm-new, xterm-r6, and gnome)?
xterm - corruption xterm-new - ditto xterm-r6 - looks ok, but monochrome gnome - problem seems to go away. I'm currently setting my TERM=xterm in my .bashrc to work around the brokenness of home/end etc when set to 'gnome'. This bug also gets hit however when ssh'ing into an FC3test1 box from an FC1/FC2 box (where TERM was 'xterm' for gnome-terminal).
I had the impression from the initial report that the problem is in slang's handling of erase, which may not be properly accounting for the cursor position in the UTF-8 configuration. It would be simple to make a reduced terminal description (probably by cancelling ech1, dch1, el1, el) to see it that's an accurate guess. But if that's right, then the fix still would be in slang - not the terminal description.
Could http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=192025&archive=yes be related? It states: "relevant code: ... SLsmg_draw_object(This_Row, This_Col, ch); // this should be removed while (n-- > 0) { SLsmg_draw_object(This_Row, This_Col, ch); } ... " I am seeing drawing errors with an mc without UTF-8 patches on FC1. Removing the above mentioned line from the slang-utf8-acs.patch at first sight seems to fix the issue for me. --- slang-utf8-acs.patch.000 2003-06-13 22:53:12.000000000 +0200 +++ slang-utf8-acs.patch 2004-08-24 18:25:39.000000000 +0200 @@ -383,13 +383,12 @@ n = (unsigned int)(cmax - cmin); count = n / 16; -@@ -1433,10 +1457,10 @@ +@@ -1433,10 +1457,9 @@ This_Color |= ALT_CHAR_FLAG; This_Col = cmin; - SLsmg_write_nchars ((char *) hbuf, n % 16); - while (count-- > 0) -+ SLsmg_draw_object(This_Row, This_Col, ch); + while (n-- > 0) { - SLsmg_write_nchars ((char *) hbuf, 16);
comment 7: i believe it is. *** This bug has been marked as a duplicate of 138445 ***
I don't think the original bugreport is related to this slang off-by-one bug in any ways... mutt doesn't draw horizontal ACS characters, and the screen (according to the screenshot) is more corrupted than just an innocent offset-by-one. Oh, wait! FC3's mutt doesn't even use slang, it uses ncursesw. I have (on a completely non-Fedora system) my mutt compiled against ncursesw (no slang) and I also faced a bug similar to the one reported originally. When I switched to a new message, which had a line with the same content (e.g. same To: line) than the previous mail, but would be displayed in a different row, then sometimes mutt wouldn't correctly print this line on its new position. This problem was caused by the indn and rin terminfo entries, which are used by mutt if available to move one line to another row (... actually I guess they are used by ncurses completely transparently to mutt... not sure though) but these terminal capabilities are not understood by vte. Dave, please reopen the bug if still appropriate, and also I recommend to try to remove these two entries from xterm's terminfo to see if it fixes your problem.
The problem only manifests when you have TERM=xterm but use gnome-terminal. I suggest you use TERM=gnome instead, which works for gnome-terminal (surprisingly enough). Home, end, pgup and pgdown work for me, too, with the suggested settings. If you find a problem with the (correct) settings of TERM=gnome, using gnome-terminal, please open a new bug for it.