Re: Aborting display. Is this possible?

[Eli Zaretskii]

> Date: Tue, 21 Oct 2014 17:14:03 +0000
> Cc: Stefan Monnier <address@hidden>, address@hidden,
>   address@hidden
> From: Alan Mackenzie <address@hidden>
> 
> > 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.
> 
> This is a red herring, surely?

No, it's a data point.  And you already got one other opinion along
these same lines.

> Tiny fractions, visible, of the line height are totally orthogonal
> to being one or two lines out (which won't even be visible) after a
> "sloppy" user action.

I ensure you they _will_ be visible.  Our users are very sharp-eyed.

> > 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?
> 
> It has got slower as it has become more accurate.  Users have complained
> about slight inaccuracies in fontification, too.  Fast enough would mean
> speeding it up by a factor of around 5.  I don't think this is
> practicable.

Of course, it's practicable!  E.g., make it by default do what CC Mode
did a few years ago.  There was time when I could scroll through
xdisp.c on a much slower machine I have today, and Emacs would keep
up, you know.  Let users who want "more accurate fontification" ask
for it, and pay the price!

I'm not saying that's necessarily what we should do, but it surely is
one way.

> > 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?
> 
> You're suggesting sacrificing fontification accuracy for scrolling
> accuracy?  :-)

That's a possibility, yes.  Fontification doesn't have to be as
accurate as the compiler.

> A very common use case for programming languages is when all the
> font-lock-* faces are mono-spaced of equal size.  This might even be the
> overwhelming majority of use.  Yet the scrolling/display code makes no
> optimisation for this.  In this very common case, it is entirely
> unnecessary to fontify bits of buffer to work out how much text would fit
> onto the screen we want to scroll over.

We've been through that already: the problem is how does the display
engine _know_ this is the case, without examining the buffer and the
text properties?  Suggest a reliable and easy to use mechanism for
that, and you've got my vote.

But assuming without any grounds that this is the situation, based on
just the mode, is a non-starter.  It will wreak havoc on many widely
used support modes.

> The whole point of Jit Lock was that we would only need to fontify the
> bits of the buffer currently being displayed.  This was partly so that
> mode maintainers could be a bit more relaxed about the speed of
> font-locking.  The scenario of auto-repeat on PageDown suggests that the
> mechanism wasn't fully thought out.

Well, think it out better, if you can.  Suggestions for algorithmic
improvements of the display engine are most welcome.

> I still say an optimisation to the scrolling code, where an option could
> specify that all faces are of the same size (or should be deemed to be
> so) is called for here.

Details, please!  What option, how it will be used, and how do we
ensure it is not abused -- these are the first issues I'd like to
hear.

And I still think you are barking up the wrong tree: the CC Mode is
slow, so it is the one that needs to be worked on.