Re: The unwarranted scrolling assumption

[Chad Brown <yandros@MIT.EDU>]

On Jun 17, 2010, at 1:17 PM, David Engster wrote:

>> It doesn't jump for me.  And, if the machine is too slow and cannot
>> keep up with the keyboard's autorepeat rate, then what's wrong with
>> the "jumps"?  What would you want Emacs to do instead, if it cannot
>> keep up with the input?
> 
> Well, you got a point there. I remember that for some time I simply used
> something like
> [...]
> 
> What I would like is that the input is somehow limited to Emacs'
> speed, but maybe this simply isn't possible?

This is the question I was trying to ask Lennart also, and I'm glad to see
both progress on an improvement and a return to the core question.  As 
I understand your answer, you're suggesting that somehow users not be 
able to press the down key faster than emacs can scroll, which seems 
like a non-starter to me.  

Many of these systems were first designed in the days where people would 
set a baud rate for the terminal connecting to the machine running emacs,
and then refined or replaced over time.  I doubt many people still use emacs
via a vt100 and a 1400 baud modem (as I once did regularly), but especially
in the era of netbooks and smartphones, we can't expect the display system 
to *always* be faster than the user.  Speeding up in the normal cases (like I 
assume yours and Lennart's) of a relatively fast local machine is a great goal,
but we do have to plan for some method of dealing with `slow' systems also.

It is almost certainly possible to add a heuristic method for emacs to throw
throw away input if it gets too far ahead of redisplay, although those code 
paths seem pretty seriously forbidding to me.  Would this be better?  Would
you want it to throw away all further input, or just scrolling?  It seems hard to 
imagine a situation in which you'd want to throw away scrolling and yet keep
text-modifying commands without somehow recognizing absolute-movement
commands (like end-of-buffer), but for that to work you need a lookahead into 
the input stream.  Such systems would need to be optional, and you'd probably 
really want a way for emacs to indicate that it had thrown away some of your
input (although maybe you could dispense with that if you could convince 
your heuristic that the `middle' scrolling was a no-op).

Hope this helps,
*Chad