Re: Aborting display. Is this possible?

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Tue, 21 Oct 2014 10:01:43 -0400
> Cc: emacs-devel@gnu.org
> 
> >> I'd posit that the absolute correctness isn't all that important after an
> >> auto-repeating PageDown.
> > That would mean that if you lean on PageDown, something catches your eye
> > while leafing through, you stop and press PageUp a few times in order to
> > locate it, it won't reappear where it caught your eye.
> 
> Could be, but it's highly unlikely: if it caught your eye, it means that
> redisplay is fast enough to keep up with scrolling, in which case
> scrolling gets to use a properly fontified buffer for its calculation,
> so Alan's suggestion should make no difference in that case.

In any case, the way Alan suggests is not TRT, IMNSHO.  We shouldn't
be sacrificing display correctness for speed; AFAIR, we never did
anything like that.  What we did was find and implement optimizations
that catered to specific use cases that were deemed important enough.
I see no reason to treat this case differently.

Another data point is this: in the recent years, I've dealt with any
number of bug reports that complained about minor inaccuracies in
scrolling, mostly by fractions of line height or even by a couple of
pixels.  My interpretation of this is that our users expect accurate
display, and will not easily tolerate sloppiness.

So I suggest to turn the table and ask: how come fontification of C
sources is so expensive, and how can we make it faster?  If the Lisp
implementation cannot be sped up significantly, let's implement some
of the code in C.  Or maybe we are should request less accurate
parsing of the source, at least by default -- e.g., perhaps it is not
very important to display variables in a face that is different from,
say, data types?

IOW, if the measurements show that redisplay takes 10% of the time,
let's not try to optimize those 10%, but instead concentrate on the
90%.