Re: Aborting display. Is this possible?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 20 Oct 2014 21:08:19 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Also, "enters redisplay" needs to be taken with a grain of salt here.
> > The reference is to display "simulation", whereby Emacs proceeds
> > through buffer text line after line, computing the metrics of the
> > characters as it goes (and invoking fontification functions if
> > needed), but doesn't store the results in glyph matrices and doesn't
> > proceed to redrawing based on that.  So it's only partial redisplay.
> > The full redisplay will be done later, after the scrolling command did
> > its part, and Emacs is back in the command loop with no available
> > input.
> 
> Yes, I've got that.  But in CC Mode, it's the fontification which takes
> most of the time (see also below).

Then I suggest to boost the speed of that.  Optimizations should be
done in the part that takes the 80 or 90% of the time.

> > There isn't really a good solution for when input comes in faster than
> > Emacs can process it.
> 
> Er, making Emacs process the input faster?

It is already very fast, as your measurements suggest.  What slows us
down is fontifications.  That's where we should try to optimize.

> > > And each such PageDown key will necessitate full font-locking for its
> > > never-to-be-displayed screen.
> 
> > No, not full, only partial.  See above.
> 
> I don't see the "above" here.  When I tested the `fontified' property
> this morning, EVERY position from point-min to point had been fontified.

I thought I've already succeeded in explaining why.

"Partial" here means that the actual drawing to the glass is not
done.  Fontifications _are_ done, because without that, Emacs would
not know where in the buffer is that point N screenfuls away.