Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!sdsu!ctrsol!srcsip!falcon!rogers
From: rogers@falcon.SRC.Honeywell.COM (Brynn Rogers)
Newsgroups: comp.emacs
Subject: Re: Kermit + emacs + ansi= slow
Keywords: kermit IBM PC ansi nansi nnansi emacs modem kitchen sinks
Message-ID: <26313@srcsip.UUCP>
Date: 25 Jul 89 14:28:03 GMT
References: <25825@srcsip.UUCP>
Sender: news@src.honeywell.COM
Reply-To: rogers@falcon.UUCP (Brynn Rogers)
Organization: Honeywell Systems & Research Center, Camden, MN
Lines: 29

In article <25825@srcsip.UUCP> rogers@src.honeywell.com (Me!) writes:
<I run kermit at home with my AT-clone and a 1200 baud modem.

<   When I run emacs and have two or more windows open I am seriously
<slowed down because most of the time scrolling up or down in a window results
<in the redrawing of that whole window, instead of just scrolling that
<window using ANSI commands.  I know it can work right because sometimes
<it does, and scrolling to a new line in one window just draws the one new
<line and goes fast. I have no Idea why it works fine in some cases but not
<others.    If I have only one window open it works fine.

I have learned a great many things and I have narrowed down the behavior
of this problem but even custom termcaps have not fixed completely.

  Whenever I have a window smaller than about 15 lines it gets completely
repainted when I just move down one line, but  if it is bigger it just
deletes one line and inserts the new one like it should. Is there something
that controls this behavior?   Looking at scroll.c (emacs source) I
can see that a large amout of effort is used to figure the cost of 
different methods of scrolling.  Why does it always choose to repaint
when the window is small? [ I have no padding whatsoever in my termcap,
scrolling regions is defined along with multiple line/character insertion
and deletion]
   



 Brynn Rogers    Honeywell S&RC        rogers@src.honeywell.com
       612-782-7737                use this address if your reply bounces