dave@CS.WISC.EDU (Dave Cohrs) (08/02/89)
Have you ever noticed that sometimes when you (scroll-up) or (scroll-down), emacs (18.54) insists on doing really ugly things to your display, like scrolling the entire display up/down (moving the banner line) and then scrolling it back again? Well, I figured out the reason behind this. When you have a message in the minibuffer, like "Mark set", and you scroll, emacs tries to "optimize" the screen refresh, and, instead of just clearing out the minibuf line, it does this wonderful scrolling stuff. Bletch! That may be more efficient on an ascii terminal (I doubt it), but on a bitmapped display, it is always ALWAYS cheaper to clean up a single line that to scroll the entire window all over the place. Below are two functions, (smooth-scroll-up) and (smooth-scroll-down) that solve the problem without trying to hack the update optimizer. You need to have the (update-display) function defined -- you can find it in the Sun or X11 support. Perhaps (update-display) should be pulled out of these packages and put in a central place? (defun smooth-scroll-up (arg) (interactive "P") (message "") (update-display) (scroll-up arg)) (defun smooth-scroll-down (arg) (interactive "P") (message "") (update-display) (scroll-down arg)) (define-key global-map "\C-v" 'smooth-scroll-up) (define-key esc-map "v" 'smooth-scroll-down)
jbuck@epimass.EPI.COM (Joe Buck) (08/04/89)
In article <8908021543.AA00534@romano.cs.wisc.edu> dave@CS.WISC.EDU (Dave Cohrs) writes: >Have you ever noticed that sometimes when you (scroll-up) or >(scroll-down), emacs (18.54) insists on doing really ugly things to your >display, like scrolling the entire display up/down (moving the banner >line) and then scrolling it back again? Emacs attempts to optimize things by sending the smallest number of characters to the screen. It thinks inserting and deleting lines is preferable to repainting because fewer characters are required. Unfortunately, this is not the appropriate metric for a bitmap display. One easy workaround is to modify your TERMCAP entry to say that "al" and "dl" require padding. (I used "2*" before the normal al and dl entries). The result is much more pleasant. It's a much cleaner solution than your elisp functions. -- -- Joe Buck jbuck@epimass.epi.com, uunet!epimass.epi.com!jbuck
jr@bbn.com (John Robinson) (08/08/89)
In article <3493@epimass.EPI.COM>, jbuck@epimass (Joe Buck) writes: >Unfortunately, this is not the appropriate metric for a bitmap >display. One easy workaround is to modify your TERMCAP entry to say >that "al" and "dl" require padding. (I used "2*" before the normal al >and dl entries). The result is much more pleasant. It's a much >cleaner solution than your elisp functions. Another improvement for some terminals and displays is multiline inserts and deletes. Note this is *standard* ANSI behavior (despite what the VT100 does!). It makes this line jumping a lot faster and easier on the bitblitter. More details in $EMACS/etc/TERMS and ...SUN-SUPPORT. -- /jr, nee John Robinson Life did not take over the globe by combat, jr@bbn.com or bbn!jr but by networking -- Lynn Margulis