Re: Unfreezing the display during auto-repeated scrolling.

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 27 Oct 2014 10:05:26 +0000
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Since you don't really care about accuracy here, ....
> 
> That was an uncalled for gibe.

It wasn't supposed to be a gibe, sorry if my wording somehow implied
that.  I really understood from what you wrote that you are willing to
sacrifice display accuracy in order to have speedier PgDown/PgUp when
leaning on the key.

> I care a great deal about accuracy here.  Perhaps we understand
> different things by "accuracy".

Perhaps.  Do you at least agree that when font-lock faces change the
font, not just colors, your changes will cause scrolling to sometimes
land on a line other than what would happen without your changes?
That's what I meant by "accuracy".

> > .... you could simply move in physical lines.  That's fast and doesn't
> > need any support from the display engine.
> 
> This would end up in the wrong place if there were as much as a single
> continued line in the window.

The same will happen with your changes, in some situations.

> And one needs to know how many lines fit in the window.

That's easy: take the window pixel size and divide by the default
font's height.

> When a user types a single PageDown/PageUp, it MUST scroll reliably
> to the right place.

So we can have a variant of scroll-up/down that behaves like today on
the first invocation, and thereafter switches to moving point
instead.  Would that do what you want?

> That involves knowing where continuation lines are, possibly where
> invisible characters are.  And one must take account of
> next-screen-context-lines, and the like.

Yes, and the gazillion other scroll-* options.  Did you already try
your changes with them?  Do you always succeed to scroll as little as
possible under scroll-conservatively, for example?

> One might argue for using different functions for, on the one hand, single
> scroll operations and scrolling over already fontified text, and on the
> other hand auto-repeated ones over non-fontified text, where the accuracy
> matters much less, but that's anything but simple, and would require
> hairy stuff somewhere.

??? What hairy stuff?  We have simple and easy-to-use mechanisms to
provide commands that change their behavior when invoked repeatedly.
For example, next-line does that.

> If I understand correctly, your notion of accuracy in scrolling
> absolutely requires that all text scrolled over must be fully fontified.

The display engine must somehow know the exact same metrics of each
screen line as the line will have when actually displayed.  The only
way we know how to do that is by "simulating display", which includes
fontification, yes.

> I don't see that this makes any sense at all on ttys

I think we use the same code on TTYs for the simple reason not to
introduce yet another separate branch in the code, which will then
have separate bugs etc.

> and in the very common case that all characters are equally big on a
> GUI.

This is IMO anti-thesis of the current GUI display engine.  It was
_created_ to free us from this assumption, which was considered
outdated 15 years ago.  It makes very little sense to me to go back to
this assumption nowadays.

And if you don't assume that, the hard problem is to _know_ when this
is the case.  We have no way of knowing that, except by scanning the
buffer.

> Why are you so opposed to such an optimisation?

Because I spent the last few years making the display engine as
accurate as possible, sometimes to (IMO) ridiculous levels, all
because users complained and demanded that, not because I invented
this attitude.  I have a very bad feeling about this change, given
that experience.

> You have asserted that my patch would lead to inaccurate scrolling.  Can
> you give a concrete example of that happening?

Just define several font-lock faces to use larger or smaller fonts,
and see if you succeed to keep the promises of the various scroll-*
options, like scroll-margin, scroll-step, scroll-up/down-aggressively
etc.

> I think I misunderstood things last night.  The display engine actually
> requires ALL text to be fontified when moving over it, doesn't it?

See above: it needs the metrics.  What parts of the text it needs the
metrics of, depends on the algorithm it uses to make its decisions, in
this case, where to set window-start for the next redisplay, and also
whether to move point back into the view.  In the case of scrolling
commands, I believe that yes, it does traverse all that text.  But
that is not carved in stone; if someone comes with an alternative
algorithm that needs to examine smaller portions of text, we can
implement scrolling that is less expensive.

> > There already is such a parameter, you just need to use it.
> 
> fontification-functions is called with just one parameter, the buffer
> position.  Where is this other size parameter?

It's the value of jit-lock-chunk-size.

> > > One might argue that CC Mode fontification should be speeded up.  Yes, it
> > > should, but it's not ever going to be speeded up by an order of
> > > magnitude.
> 
> > I don't see why not.  We could rewrite that stuff in C.
> 
> Patches welcome.  ;-)

Not from me, sorry.  I don't know enough about the underlying syntax
infrastructure, and don't have enough motivation to learn that.

And you still didn't reply to my suggestion to use jit-lock-defer-time.
In my testing, setting it to 0.05 sec is enough to give you what you
want, for free.  That is just another evidence that we already have
enough knobs in our arsenal to solve these problems when they annoy
someone.  E.g., I always have jit-lock-stealth turned on, so my
buffers are always fully fontified, except in the few first moments of
a session (something that happens rather rarely).  This allows me to
avoid the problem entirely, without sacrificing accuracy.