Red Hat Bugzilla – Bug 127700
text overwrites previous email.
Last modified: 2015-01-04 17:07:44 EST
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.
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.
related? It states:
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
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.