Re: Aborting display. Is this possible?

[Alan Mackenzie]

Hi, Eli.

On Sun, Oct 19, 2014 at 05:50:52PM +0300, Eli Zaretskii wrote:
> > Date: Sun, 19 Oct 2014 14:17:13 +0000
> > From: Alan Mackenzie <address@hidden>

> > A lisp program can influence an ongoing display operation by setting
> > redisplay-dont-pause to nil.  When input arrives, the displaying is
> > immediately paused.

> It is not paused, it is aborted.  Emacs cannot "pause" redisplay and
> then "resume" it.

Ah.  OK.

> > However, at the next opportunity, the displaying carries on where it
> > left off, rather than being aborted.

> I don't understand what you mean by "carries on where it left off".
> Emacs doesn't record where redisplay "left off", and cannot resume an
> interrupted redisplay cycle.  It simply starts redisplay anew on the
> next opportunity.

I asked for it, it seems I've got it already.

> > Why?  Better to handle a user auto-repeating on the PageDown key.  On my
> > system, auto-repeat is around 35-40 characters per second, on a window
> > with 65 lines.  In my favourite mode, display can not keep up.  If I set
> > redisplay-dont-pause to nil and hold down PageDown, what the user sees
> > is frozen for several seconds whilst display determines the display of
> > every intermediate buffer position (which isn't going to get displayed
> > anyway) before finally reaching point.

> That's not what happens.  What does happen is that redisplay _tries_
> several times to do its job, right after each PageDown keypress, each
> time starting with the value of point it sees, then abandoning that
> attempt because input arrives before it could finish.

So if 35 PageDowns are received in a second, it starts redisplay after
each and every one.  How much time does it take before checking for
pending input?

Could my problem be that this time is short enough that that no
intermediate screen has time to display a fragment, but long enough that
there's a significant pause when the user finally takes her finger of
PageDown?

What is stopping a fragment of each intermediate screen (or of some of
them) being displayed?  Could it be that the display engine calculates an
entire screenful of glyphs before it starts displaying them on the
physical screen?

> Emacs never examines portions of the buffer that don't need to be on
> the screen (or a few lines of text above or below that).  It always
> starts with the current value of point, and works from that.  So
> intermediate buffer positions will never be examined.

> > Would it be possible to enhance display such that incoming input would
> > abort the current display operation?

> It does already.  Emacs simply doesn't know any better.

-- 
Alan Mackenzie (Nuremberg, Germany).