Xref: utzoo gnu.emacs:1407 gnu.emacs.bug:1049 comp.emacs:6660
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!gatech!tut.cis.ohio-state.edu!ukma!xanth!talos!kjones
From: kjones@talos.uucp (Kyle Jones)
Newsgroups: gnu.emacs,gnu.emacs.bug,comp.emacs
Subject: Re: Scrolling in GNU emacs
Message-ID: <1989Aug14.153236.13162@talos.uucp>
Date: 14 Aug 89 15:32:36 GMT
References: <8914@cbnews.ATT.COM> <TOM.89Aug10071424@hcx2.ssd.harris.com>
Reply-To: kjones%talos.uucp@uunet.uu.net
Lines: 19

Tom Horsley writes:
 > You would think that if a terminal has scrolling regions, it would
 > *always* be faster to scroll, but it does some sort of cryptic computations
 > that wind up deducing it is faster to redraw the whole screen than to
 > scroll:

Ho ho, just recently we had some users of X windows moaning that the
opposite is true.

It really and truly depends on what exactly is on the screen and how
much padding for the terminal's scrolling commands, be they scrolling
regions, scrolling forward/backward, or insert/delete line or all of
these.  In the case of windowing systems that don't provide a termcap (or
equivalent) information, then whether scrolling is fast or not depends
on the hardware driving the bitmapped display.

So if Emacs is making the wrong decision between scrolling and redrawing
then more than likely it's been given incorrect (or no) information to
work with.