egkle@mimsy.UUCP (E G K Lopez Escobar) (01/18/89)
Hello,
I have a question about how GNU Emacs scrolls text in windows.
When I move point past the top or bottom of the displayed text in a
window, Emacs scrolls the text in the appropriate direction so as to
center point vertically in the window. Most of the time it seems to
do this via something like the following (this particular sequence is
what happens when I have a single window displayed and do C-n with
point on the last line of a window):
(1) the mode-line moves up to about the middle of the window
"pushing" the text above it past the top of the window,
(2) then the mode-line moves back down to its normal position,
leaving blank space in the lower half of the window,
(3) then Emacs fills in the blank space with more text from the
buffer.
This is all fine if I'm working on a fast workstation or a
terminal with a high baud rate, because it all happens so fast I
hardly notice it. But in most situations, steps (1), (2), and (3)
take several seconds each, which is annoying when I'm trying to flip
quickly through my file. The frustrating thing is that this doesn't
happen ALL the time, which makes me think there must be some way to
turn it off. Sometimes, usually when I'm using C-v or M-v to do the
scrolling myself, Emacs just redisplays the text, without the
mode-line dancing around, and it happens much faster.
Is there a way to tell Emacs do the faster scrolling all the
time? I have checked the info pages for scrolling and controlling the
display, but I couldn't find anything. In case it matters, I'm using
GNU Emacs 18.48.15 on a Sun workstation running SunOS 3.5, and I
usually run Emacs from within emacstool in Suntools, although it
exhibits the same behavior when run from within a cmdtool, or even
just on the whole screen outside of Suntools.
If you reply directly, don't use 'r' or the address in the header,
because I'm not submitting this from my own account. Use one of the
addresses below. Thanks.
Mark Phillips
Department of Mathematics
University of Maryland
College Park, Maryland
mbp@lakisis.umd.edu
OR mbp%lakisis.umd.edu@eneevax.umd.edukjones@talos.UUCP (Kyle Jones) (01/18/89)
In article <15494@mimsy.UUCP> egkle@mimsy.UUCP (E G K Lopez Escobar) writes:
[ Asks for help speeding up scrolling on Sun workstations ]
In the Emacs distribution the file etc/TERMS discusses terminal
problems like yours. In particular, near the end of the file:
The Sun console should have these capabilities for good performance.
:AL=\E[%dL:DL=\E[%dM:IC=\E[%d@:DC=\E[%dP:
Add the above line to your `sun' termcap entry (or get your sysdamin
to do it) and scrolling will be much faster.jr@bbn.com (John Robinson) (01/18/89)
In article <15494@mimsy.UUCP>, egkle@mimsy (E G K Lopez Escobar) writes: > (1) the mode-line moves up to about the middle of the window > "pushing" the text above it past the top of the window, > (2) then the mode-line moves back down to its normal position, > leaving blank space in the lower half of the window, > (3) then Emacs fills in the blank space with more text from the > buffer. This is how emacs will update the screen using the terminal's "insert-line" and "delete-line" capabilities. The latter deletes the line the cursor is on (typically, line 1) and the former inserts a blank line at the cursor moving the following lines DOWN (and dropping the last line off the bottom). As Jeff Peck pointed out, multi-line add- and delete-line capabilities make this all a lot faster, and the Sun terminal emulator can do them. The content of his message (plus a bunch of other goodies) is included with the distribution in the file ...emacs/etc/SUN-SUPPORT. Note that the VT100 and imitators have a different way to move a section of the screen up or down. It requires setting the "scrolling region"; once that is done, index and reverse-index operations shift the screen within the region by one line, dropping off a line at the top or bottom of the region and leaving everything outside as-is. This is MUCH nicer for editors and your eyes. I believe emacs will use this feature if it is available. > The frustrating thing is that this doesn't >happen ALL the time, which makes me think there must be some way to >turn it off. Sometimes, usually when I'm using C-v or M-v to do the >scrolling myself, Emacs just redisplays the text, without the >mode-line dancing around, and it happens much faster. The code in dispnew.c and xdisp.c figures out what is "best" to do, where "best" takes into account the amount of delay that must be inserted when fancy operations require padding. See termcap(5) or terminfo(5) if you have that. (I will use termcap to stand for this pair in the following.) It may look slow, but a complete redisplay would probably be slower still, though a little less jarring to the eyes. If the scroll-region approach is cheaper (taking into account padding of the scroll-region command, plus its extra length), emacs should use that. Note that the cost calculation may have to make worst-case assumptions about padding due to the inability of the termcap model to express hairy padding requirements. This may cause it to make sub-optimal choices which a hand-coded driver for a given terminal may do better at. emacs, however, has the advantage of being very general (with termcap's help). > Is there a way to tell Emacs do the faster scrolling all the >time? One reason emacs makes poor scrolling choices is that it doesn't really know the speed of the terminal. If you are talking through a network (say with rsh or login or telnet), your terminal speed is often set to something like 38400. Yet you may have a slow serial line between your terminal and emacs. For network connections, the terminal speed is irrelevant, so you should set it to reflect the "actual" speed of the slow link. No doubt you can also do this for suntool and cmdtool. This will change the cost calculations and perhaps make emacs seem more zippy. Also, it will change the incremental search behavior if you set it slow enough. See search-slow-speed. Another approach is to lie in the termcap entry to make the operations you don't like seem overly expensive. This may lead to other behavior you don't like either, like repainting the whole screen when scrolling by one line. > In case it matters, I'm using >GNU Emacs 18.48.15 on a Sun workstation running SunOS 3.5, and I >usually run Emacs from within emacstool in Suntools, although it >exhibits the same behavior when run from within a cmdtool, or even >just on the whole screen outside of Suntools. Hmmm... I don't know how emacs figures out a terminal "speed" when you start a emacstool. Maybe it makes too optimistic an assumption. Although the main assumption that the "cost" of a terminal operation is the number of characters it must send is clearly broken when you are talking about IPC to a piece of software that is pretending to be a terminal. Printing a character into the bitmap is far cheaper than "printing" a linefeed at the window end, with the attendant scrolling. > Mark Phillips > Department of Mathematics > University of Maryland > College Park, Maryland > > mbp@lakisis.umd.edu > OR mbp%lakisis.umd.edu@eneevax.umd.edu -- /jr jr@bbn.com or bbn!jr