Bug 135159 - lines don't refresh and scrolling wraps in middle of terminal
Summary: lines don't refresh and scrolling wraps in middle of terminal
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: nano
Version: 3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Woodhouse
QA Contact:
URL:
Whiteboard:
Depends On: 1348820 1365759
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-10-09 14:07 UTC by Jan Wagner
Modified: 2016-11-28 12:52 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-10-30 15:19:26 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jan Wagner 2004-10-09 14:07:30 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Gecko/20040904 Firefox/0.9.3

Description of problem:
When I edit any text file that is longer than the current
gnome-terminal window and scroll down beyond the page (cursor keys),
the text scrolling starts only from the middle of the terminal text.
The upper half remains static. I.e. the text scrolls in the lower half
only. In addition, scrolled-in lines overwrite the current text but
don't clear the remainder of the line => mess. Same thing when
scrolling upwards, though opposite (lower half static, upper 'scrolls'
to a mess).
vi, vim and emacs work just fine.

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

How reproducible:
Always

Steps to Reproduce:
1. nano anyLongTextDocument
2.
3.
    

Expected Results:  Proper scrolling of entire visible text, and clean
line clears.

Additional info:

Comment 1 Per Bjornsson 2004-10-21 16:06:33 UTC
I see this too in a gnome-terminal window, but it actually works OK in
a plain xterm. Nano worked fine in gnome-terminal in FC2; has the
redrawing somehow been optimized in a way that works in xterm but
doesn't in gnome-terminal?

Clearly nano has a correct idea of what should be on the screen
somewhere, since a terminal refresh (^L) gives the correct screen
contents.

(Same nano version, 1.2.4-1, still in Rawhide as of 10/21/04)

Comment 2 Per Bjornsson 2004-11-11 18:58:48 UTC
This appears to be a duplicate of #127972. I put a comment in that
bug; I think that the problem is fixed in Rawhide vte. 

Comment 3 Alexandre Strube 2005-04-21 15:39:26 UTC
does this have to do with ncurses bug which prevents home and end keys to work?
Was it fixed?

Comment 4 Alejandro Gonzalez Hernandez - Imoq 2005-04-21 16:35:22 UTC
This is, indeed, a duplicate of bug #127972 and should be closed as "DUPLICATE".


Comment 5 Matthew Miller 2006-07-10 20:09:51 UTC
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!


Comment 6 John Thacker 2006-10-30 15:19:26 UTC
Closing per lack of response to previous request for information.  This bug was
originally filed against a much earlier version of Fedora Core, and significant
changes have taken place since the last version for which this bug is confirmed.
 It has remained in NEEDINFO status for quite a long period of time, asking for
confirmation on a more recent (still fully supported) version of Fedora Core.

Note that FC3 and FC4 are supported by Fedora Legacy for security
fixes only.  Please install a still supported version and retest.  If
it still occurs on FC5 or FC6, please reopen and assign to the correct
version.  Otherwise, if this a security issue, please change the
product to Fedora Legacy.  Thanks, and we are sorry that we did not
get to this bug earlier.


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