Xref: utzoo gnu.emacs:1414 gnu.emacs.bug:1054 comp.emacs:6670
Path: utzoo!utgpu!watmath!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!att!cbnews!djs
From: djs@cbnews.ATT.COM (Douglas J. Scofea)
Newsgroups: gnu.emacs,gnu.emacs.bug,comp.emacs
Subject: Re: Scrolling in GNU emacs
Message-ID: <9019@cbnews.ATT.COM>
Date: 15 Aug 89 21:47:31 GMT
References: <8914@cbnews.ATT.COM> <TOM.89Aug10071424@hcx2.ssd.harris.com> <1989Aug14.153236.13162@talos.uucp>
Reply-To: djs@cbnews.ATT.COM (Douglas J. Scofea)
Organization: AT&T Bell Laboratories
Lines: 67

In article <1989Aug14.153236.13162@talos.uucp> kjones%talos.uucp@uunet.uu.net writes:

>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:
>
>
>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.

Yes, but as I said in the original article, my terminal requires no
padding.  Thus, it didn't seem to make sense to redraw the screen
when a few escape sequences would suffice.  In my case, emacs would
redraw 64 lines to save a few escape sequences, hardly optimal redisplay.  

Thanks to those who posted the suggestions for the terminfo descriptions.  
However, none of them helped.  I think I've found the problem.  Tom
Horsley gave me a good hint when he pointed out that there was a comment
in xdisp.c that short lines were ignored when calculating the cost
of screen updates.  I tried some changes and finally tracked it
down to a routine called scrolling_max_lines_saved in scroll.c that
tries to calculate how many lines are the same between the old
display and the new display.  Unfortunately, it ignores lines of
less than 20 characters.  Thus, if all (most?) of the lines are
less than 20 characters, it feels that very little of the display
lines are the same and redraws the entire display.  I changed the
code to eliminate that test for greater than 20 character line length.
It may cause some new bugs, I haven't found any, but I can't say
I have a complete understanding of the display code.  If anyone
knows a better way to fix this, please let me know.  In any case
a context diff is given below of the change I made.  It was made
from GNU emacs 18.53.  Good luck.

*** scroll.c.orig	Tue Aug 15 13:12:51 1989
--- scroll.c	Tue Aug 15 14:14:41 1989
***************
*** 316,327
    /* Put new lines' hash codes in hash table.  */
    for (i = start; i < end; i++)
      {
!       if (cost[i] > 20)
! 	{
! 	  h = newhash[i] & 0777;
! 	  lines[h].hash = newhash[i];
! 	  lines[h].count++;
! 	}
      }
  
    /* Look up old line hash codes in the hash table.

--- 316,324 -----
    /* Put new lines' hash codes in hash table.  */
    for (i = start; i < end; i++)
      {
!       h = newhash[i] & 0777;
!       lines[h].hash = newhash[i];
!       lines[h].count++;
      }
  
    /* Look up old line hash codes in the hash table.
-- 
Doug Scofea  -  douglas.j.scofea@att.com      Phone: +1 614 860 2065
UUCP:   ...!att!cblpn!djs