[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Aborting display. Is this possible?

From: Eli Zaretskii
Subject: Re: Aborting display. Is this possible?
Date: Mon, 20 Oct 2014 20:40:07 +0300

> Date: Mon, 20 Oct 2014 20:10:07 +0300
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden, address@hidden
> > > Now, what happens when you release the key?  The input queue is still
> > > full of unprocessed PageDown keys.
> > 
> > If processing a single scroll-up-command takes less time than the repeat
> > rate, the input queue should never have many unprocessed PageDown events
> > (that's the whole reason why we check the input queue before entering
> > redisplay).
> > 
> > So I still don't understand why we see this long delay when releasing
> > the key.
> Not every screenful needs the same time to redisplay.  There comes a
> screen that needs more, and the queue is no longer empty.

In addition, there are 2 places where auto-repeated keystrokes wait:
one is the Emacs keyboard buffer, the other is the system input queue,
since when we process keys we don't call the read_socket_hook.

If you put a breakpoint in kbd_buffer_store_event and
kbd_buffer_get_event, and define breakpoint commands that display the
queue size, you will see that when you release the key, the queue size
decreases to zero, then jumps to a large number, then decreases again,
and finally the window is redisplayed.

To me this means we have a lot of unprocessed keys in both queues.
IOW, when the queue fills up because some screen took too long to
display, Emacs doesn't succeed in emptying it, as long as the key is

reply via email to

[Prev in Thread] Current Thread [Next in Thread]