From:	CRDGW2::CRDGW2::MRGATE::"SMTP::PREP.AI.MIT.EDU::INFO-GNU-EMACS-REQUEST" 15-AUG-1989 21:36
To:	MRGATE::"ARISIA::EVERHART"
Subj:	Re: Scrolling in GNU emacs

Received: by life.ai.mit.edu (4.1/AI-4.10) id AA09834; Tue, 15 Aug 89 20:11:43 EDT
Return-Path: <info-gnu-emacs-request@prep.ai.mit.edu>
Received: from tut.cis.ohio-state.edu by life.ai.mit.edu (4.1/AI-4.10) id AA09755; Tue, 15 Aug 89 19:59:48 EDT
Received: by tut.cis.ohio-state.edu (5.61/4.890725)
	id AA09074; Tue, 15 Aug 89 19:48:56 -0400
Received: from USENET by tut.cis.ohio-state.edu with netnews
	for info-gnu-emacs@prep.ai.mit.edu (info-gnu-emacs@prep.ai.mit.edu)
	(contact usenet@tut.cis.ohio-state.edu if you have questions)
Date: 15 Aug 89 21:47:31 GMT
From: att!cbnews!djs@cis.ohio-state.edu  (Douglas J. Scofea)
Organization: AT&T Bell Laboratories
Subject: Re: Scrolling in GNU emacs
Message-Id: <9019@cbnews.ATT.COM>
References: <8914@cbnews.ATT.COM>, <TOM.89Aug10071424@hcx2.ssd.harris.com>, <1989Aug14.153236.13162@talos.uucp>
Sender: info-gnu-emacs-request@prep.ai.mit.edu
To: info-gnu-emacs@prep.ai.mit.edu

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
