Re: C-n is very slow in Font-Lock mode

[David Kastrup <dak@gnu.org>]

Richard Stallman <rms@gnu.org> writes:

>     > It turns out that vertical-motion was fontifying all the text that
>     > it moved over.  That seems to be easy to fix.
>
>     Did you try my suggestion of customizing jit-lock-defer-time?
>
> No, because I want to fix this, not work around it.  vertical-motion
> is a cursor motion function.  It should not fontify anything.

vertical-motion is a built-in function in `C source code'.
(vertical-motion LINES &optional WINDOW)

Move point to start of the screen line LINES lines down.
If LINES is negative, this means moving up.

This function is an ordinary cursor motion function
which calculates the new position based on how text would be displayed.
The new position may be the start of a line,
or just the start of a continuation line.

[...]

I don't see how vertical-motion can be expected to calculate the new
position based on how text would be displayed if it is not allowed to
figure out how text would be displayed.

So for its correct behavior, it is mandatory to do the font locking.
The only exception to that would be if the user would have specified
that it is ok to work with unfontified text.

One way to do that is to set jit-lock-defer-time.  I think it would be
reasonable if jit-lock-defer-time (currently defaulting to nil) would
instead default to 0, with 0 meaning that font locking will occur
without delay before displaying stuff, but not otherwise (maybe that
setting already does that, but I have not checked).

This would mean that paging back and forth over previously
nonfontified stuff would not necessarily lead to the same position,
but that still no surprisingly unfontified stuff would show up on the
display.

But with the current settings, it appears to me that vertical-motion
can't reasonably do something different.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum