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): vim-minimal-6.4.007-4 gnome-terminal-2.14.0-1 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).
Created attachment 126341 [details] gnome-terminal screenshot (see the bottom-most line).
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?
vte-0.12.0-1.fc5.1 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).
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 text. 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.
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.
Fedora Core 5 is no longer maintained. Is this bug still present in Fedora 7 or Fedora 8?
No, I believe it has disappeared sometimes during the FC5-FC6 lifetime. Thanks goes to the Fedora maintainers for the fast response :-/