🚀 go-pugleaf

In article <j32m7!f.bskendig@netcom.com> bskendig@netcom.com (Brian Kendig) writes:
>When I used Emacs on my university's machines, whenever I'd kill
>(delete) a line of text, all the text below the line I just killed
>would be shifted up by one line to fill in the gap.  If there was more
>text past the bottom of the screen, then one new line would be drawn
>at the bottom of the screen to fill in that gap.  Perfectly normal
>behavior, and the scroll looked like it was a feature supported by the
>terminal -- that is, it didn't have to take time redrawing each line
>right above its old position, it just shifted a block of text up.
>
>But when I use Emacs on the Netcom system, killing a line does redraw
>every line (below where I just killed) right above its old position!
>This is painfully slow with my 2400 baud modem, and even with a 9600
>baud modem it's sluggish, especially if I'm deleting lines near the
>top of the screen.
>
>Is there any way I can get Emacs to scroll a block of text up on my
>screen instead of redrawing all of it?  I mean, is there some
>parameter I can set in my .emacs file that would fix this?  I'm using
>a vt100, so I *thought* this kind of thing would be handled
>automatically... maybe it's a bad termcap entry?
>
Yes, Emacs seems rather stupid in this sense.  Go use Jove.
It's similar to Emacs.  And it won't resend the slew of lines
under the line you deleted, just the one line.

Gene