Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!unido!sbsvax!roeder
From: roeder@sbsvax.UUCP (Edgar Roeder)
Newsgroups: comp.sys.atari.st
Subject: Re: Scrolling in GnuEmacs 18.51 on the Atari ST
Summary: use another termcap entry, or - do you want the new version ?
Keywords: Emacs, Termcap
Message-ID: <1823@sbsvax.UUCP>
Date: 14 Dec 89 20:48:32 GMT
References: <1756@ultb.isc.rit.edu>
Organization: Universitaet des Saarlandes, Saarbruecken, W-Germany
Lines: 53

In article <1756@ultb.isc.rit.edu>, sto9719@ultb.isc.rit.edu (S.T. Organek) writes:
> Has anyone else had a problem with the scrolling that Gnuemacs 18.51 
> does on the Atari ST.  The problem I have found is that when the screen
> scrolls, the status bar also moves and gives the appearance of an a
> window shade.  Does anyone have an idea what this might be.  Some said
> something about the termcap I am using.   
> 

 Yes indeed this has to do with the termcap entry. The emacs display routines
were designed to minimize the traffic of bytes over a serial line from the
computer to the actual display device (a terminal). Therefore emacs thinks that
sending an escape sequence of two characters to delete/insert a line is
faster than sending say 40 bytes of blank characters to delete the data
displayed in this line. This may be true for a terminal, but on the st with
it's graphic screen, the former operation could take some more time.

 The termcap-database format has a method to say how "expensive" an operation
may be: the amount of padding needed. So all you have to do is to say emacs,
that either the operations add line (al) and delete line (dl) are very
expensive (you can specify eg. "al=80*\EL:dl=80*\EM" in your termcap entry),
or you can ommit those features, so that emacs will no longer use them.

 But a word of warning: emacs uses this padding information (the number before
the '*') for calculating the cost of the operation and then tries the cheapest
way to reach its goal. Other programs may think, that the terminal needs
80-times the time as required to send the escape sequence to perform the actual
operation. To do something while "waiting for the terminal to complete the
operation", they may then decide to send some NUL-characters to the screen
(those would be ignored by normal terminals). As a consequence the program will
slow down even more - the st has to process those padding bytes too :-).

********
* BTW: *
********
I have a new (dumpable) version (18.55) ready. The dumped emacs has a
size of 520 kB (360 kB packed) and leaves about 110 kB free on a 1MB ST (i
would recommend using at least 2 MB - personally i use it with a 800 kB
RAM-disk on my Mega ST2). It has (among other improvements):
	- mouse support
	- Interrupts (via ^G or ^Z) at any time (eg during loading of files)
	- suspend-emacs works with gulam too
	- shell-mode works (well at least with Master)
	- filenames of backup-files adapted to the st-limitations
If there is enough interest, i could post temacs (that's the raw, undumped
version), the standard-lisp-files and my postprocessor to relocate the image.
The termcap problem above remains the same (it's inherent to the display
routines).

> 
> 			STeve Organek 
> 

	- Edgar