Re: The unwarranted scrolling assumption

[David Engster]

Chad Brown writes:
> On Jun 17, 2010, at 1:17 PM, David Engster wrote:
>> What I would like is that the input is somehow limited to Emacs'
>> speed, but maybe this simply isn't possible?

> 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).

Yes, I see that this isn't really feasible. I really don't know enough
of the Emacs display engine to make any suggestions how this problem
might be tackled. I know that Emacs is special in this regard since it
enforces that the point position is always visible, and that scrolling
is actually more of a side-effect. However, in this case, I want the
opposite: I first and foremost want to scroll the buffer, with point
movement being a side-effect. I know that I can use the scroll-bars, but
their scrolling behavior is far from smooth in large buffers (and I have
them disabled anyway).

-David