sto9719@ultb.isc.rit.edu (S.T. Organek) (12/14/89)
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. Thanks for help in advance. STeve Organek STO9719@RITVAX.BITNET rochester!ultb!sto9719 rochester!ur-valhalla!asyst!sto
roeder@sbsvax.UUCP (Edgar Roeder) (12/15/89)
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
johnb@pnet01.cts.com (John Bunch) (12/19/89)
Could you please post your new version....
John.
UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!johnb
ARPA: crash!pnet01!johnb@nosc.mil
INET: johnb@pnet01.cts.com