delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2001/07/31/13:59:22

Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
From: hans DOT deragon AT visa DOT desjardins DOT com
Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_Scrolling_problems_with_rxvt=2E?=
To: cwilson AT ece DOT gatech DOT edu
Cc: cygwin AT cygwin DOT com
Date: Tue, 31 Jul 2001 13:19:06 -0500
Message-ID: <OFE17A6B13.2AB21FF5-ON05256A9A.00644C20@pub.desjardins.com>
X-MIMETrack: Serialize by Router on SMTP01/SRV/DESJSMTP01/Desjardins(Release 5.0.6a |January
17, 2001) at 2001/07/31 01:37:32 PM
MIME-Version: 1.0

Greetings.


  Actually, the problem does not occur in an editor like vim, but when at the bash
  prompt.  What you explained is right, but it is not the problem I suffer from.  I
  am at my bash prompt, run a command like ls -l, then scroll up the window and
  behold, the data shown is not that of the beginning of the ls -l command.

  There seams to be serious problem with the buffer/scrolling routines of rxvt.


Thanks for replying.
Hans





Charles Wilson <cwilson AT ece DOT gatech DOT edu> le 07/31/2001 10:50:12 AM

Pour :    hans_deragon/visa/desjardins AT visa DOT desjardins DOT com
cc :  cygwin AT cygwin DOT com
Objet :   Re: Scrolling problems with rxvt.


hans DOT deragon AT visa DOT desjardins DOT com wrote:


>   http://sources.redhat.com/ml/cygwin/2001-06/msg00652.html -->
>   When scrolling up past 1 screen in the rxvt term, what you see is not
>   what is just preceeding in the file - stuff is lost and what you see is
>   much earlier (older) output.
>   <--


Not exactly.  You see, some programs (like less and vi) actually use a
secondary display buffer.  If you use the arrow keys, you can tell less
(or vi) to change what portion of the file they display in that
one-screenfull-tall buffer.  However, if you use the scroll bar, you
then see the primary buffer contents.

That is, less/vim will always ONLY control ONE screenful of data.  If
you scroll OUT of that screenful, then you see .... bash?

This behavior is what allows bash(?) to restore the previous "bash"
display after you exit vi or less.

Summary: not a bug.


>   http://sources.redhat.com/ml/cygwin/2001-06/msg00390.html -->
>   running the latest version of rxvt it appears that, under certain
>   conditions (several hours of use), the scroll bar "fills up" and no
>   longer functions. That is, it looks exactly like it does when the
>   window is created and there is nothing to scroll.
>   <--


I use rxvt exclusively, in both X and native modes.  I've never seen this.

--Chuck






--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019