Bug 127700 - text overwrites previous email.
text overwrites previous email.
Product: Fedora
Classification: Fedora
Component: ncurses (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Petr Rockai
Depends On:
  Show dependency treegraph
Reported: 2004-07-12 14:36 EDT by Dave Jones
Modified: 2015-01-04 17:07 EST (History)
3 users (show)

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

Attachments (Terms of Use)
email showing bits of previous email in headers. (145.48 KB, image/png)
2004-07-12 14:37 EDT, Dave Jones
no flags Details

  None (edit)
Description Dave Jones 2004-07-12 14:36:46 EDT
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.
Comment 1 Dave Jones 2004-07-12 14:37:42 EDT
Created attachment 101820 [details]
email showing bits of previous email in headers.
Comment 2 Thomas E. Dickey 2004-07-13 20:32:06 EDT
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.
Comment 3 Bill Nottingham 2004-08-05 12:53:18 EDT
AFAIK, this is because of the xterm/gnome/etc terminfo 'fun'.
Comment 4 Eido Inoue 2004-08-05 13:55:54 EDT
can you tell me if the problem occurs with other settings for TERM
(xterm, xterm-new, xterm-r6, and gnome)?
Comment 5 Dave Jones 2004-08-05 14:08:43 EDT
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).

Comment 6 Thomas E. Dickey 2004-08-05 15:35:20 EDT
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.
Comment 7 Leonard den Ottolander 2004-08-24 12:34:55 EDT
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 8 Eido Inoue 2004-11-12 15:36:58 EST
comment 7: i believe it is.

*** This bug has been marked as a duplicate of 138445 ***
Comment 9 Egmont Koblinger 2004-11-12 16:03:50 EST
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.
Comment 10 Petr Rockai 2005-02-18 05:46:52 EST
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. 

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