Bug 185945 - garbled screen with vi scroll down
Summary: garbled screen with vi scroll down
Alias: None
Product: Fedora
Classification: Fedora
Component: vte
Version: 5
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-03-20 11:07 UTC by Jan "Yenya" Kasprzak
Modified: 2008-08-02 23:40 UTC (History)
0 users

Fixed In Version: F7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-03-11 09:55:25 UTC
Type: ---

Attachments (Terms of Use)
gnome-terminal screenshot (see the bottom-most line). (25.73 KB, image/png)
2006-03-20 11:07 UTC, Jan "Yenya" Kasprzak
no flags Details

Description Jan "Yenya" Kasprzak 2006-03-20 11:07:53 UTC
Description of problem:
When I use vi(1) in gnome-terminal, and scroll down using the "j" key, the last
line of the screen is not overwritten correctly, and the previous contents of
the line (or even mix of few previous lines) remains there.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. run gnome-terminal
2. run vi /etc/X11/xorg.conf inside the terminal (or whatever file with variable
lengths of the lines)
3. scroll down few times using the "j" key (or down arrow), untill you find a
line shorter than the previous one.
Actual results:
The text from the shorter line is displayed, and after this remains the text
from previous (longer) lines.

Expected results:
The shorter line should be displayed correctly.

Additional info:
I have tested it on x86_64, but I don't think it is x86_64 specific.

I am not sure whether it is a gnome-terminal bug at all (it may be a vim-minimal
bug as well - when using vim(1) instead of vi(1) I am not able to reproduce
this). However, in xterm(1x) it works as expected.

While grabbing the screenshot I have found that gnome-terminal probably has
right idea on what the screen contents should be, but its X window is not
updated correctly - when I obscure the terminal window by some other window and
then unobscure it back, the last line gets redrawn correctly. Anyways, the
screen shot attached (see the bottom-most line of the terminal window - in the
file itself the line after "EndSection" is empty).

Comment 1 Jan "Yenya" Kasprzak 2006-03-20 11:07:53 UTC
Created attachment 126341 [details]
gnome-terminal screenshot (see the bottom-most line).

Comment 2 Ray Strode [halfline] 2006-03-31 03:25:20 UTC
What version of vte do you have installed?

if you open a terminal, run gnome-terminal --disable-factory, run vi in the new
terminal that pops up and then reproduce the bug does the first terminal get any
warning messages?

Comment 3 Jan "Yenya" Kasprzak 2006-03-31 05:42:36 UTC

I can also reproduce this in newly started gnome-terminal --disable-factory.
No warning messages at all.

It may be related to the Radeon driver in X - all hosts I have tried to
reproduce this on have ATI graphics (altough it is a wide variety of them - one
of them is even an ATI IXP-equipped laptop).

Comment 4 Clem Taylor 2006-04-06 20:19:00 UTC
I see this same problem on x86_64 with vile and I have a nvidia card (using
the nvidia driver).

A 'ctrl-l' will cause the screen to redraw correctly.  Also, forcing the
window repainted will (via iconify or occulsion) result correctly rendered

Another strange thing is that if, in vile, I split the screen horzontally
(ctrl-x 2), scrolling down (j) in the bottom sub-window will redraw correctly,
but scrolling down in the top sub-window will result in the redraw bug.

Comment 5 Jan "Yenya" Kasprzak 2006-05-24 11:07:25 UTC
I believe NEEDINFO is not a correct status of this bug. I am changing the status
to VERIFIED. If there is any further info Fedora maintainers need, please
specify and change back to NEEDINFO.

Comment 6 petrosyan 2008-03-11 01:45:12 UTC
Fedora Core 5 is no longer maintained. Is this bug still present in Fedora 7 or
Fedora 8?

Comment 7 Jan "Yenya" Kasprzak 2008-03-11 09:55:25 UTC
No, I believe it has disappeared sometimes during the FC5-FC6 lifetime.
Thanks goes to the Fedora maintainers for the fast response :-/

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