Re: Unfreezing the display during auto-repeated scrolling.

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Mon, Oct 27, 2014 at 05:36:32AM +0200, Eli Zaretskii wrote:
> > Date: Sun, 26 Oct 2014 22:15:30 +0000
> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > Maybe Eli's suggestion of rewriting scroll-up and scroll-down from
> > scratch in Elisp could work, but if I'm not mistaken, there's no
> > infrastructural support for window lines, etc., which doesn't involve
> > fontification.  This would have to be written.

> Since you don't really care about accuracy here, ....

That was an uncalled for gibe.  I care a great deal about accuracy here.
Perhaps we understand different things 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.  And one needs to know how many lines fit
in the window.  When a user types a single PageDown/PageUp, it MUST
scroll reliably to the right place.  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.

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.

If I understand correctly, your notion of accuracy in scrolling
absolutely requires that all text scrolled over must be fully fontified.
I don't see that this makes any sense at all on ttys, and in the very
common case that all characters are equally big on a GUI.

All I need for fast scrolling is some way of telling the display code
that all characters are the same size, and that fontification is thus
necessary only for display.  Why are you so opposed to such an
optimisation?

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

> > If movement on a window absolutely requires fontified characters, then
> > some means will need to be found for the display code to tell jit-lock
> > HOW MUCH needs fontifying, and for that amount to be much less than 500
> > bytes in the non-display case.

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

> 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?

> > 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.  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).