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

[David Kastrup]

"Eli Zaretskii" <address@hidden> writes:

>> Cc: address@hidden, address@hidden
>> From: David Kastrup <address@hidden>
>> Date: Tue, 26 Apr 2005 23:38:11 +0200
>> 
>> > I think jit-lock-defer-time _is_ the way to avoid the slowness if
>> > you are willing to see the text unfontified for a fraction of a
>> > second.
>> 
>> I think that a separate value of 0 where is one not willing to see
>> text unfontified, but willing to have motion calculated with a
>> still unfontified text, would make perfect sense.
>
> jit-lock-defer-time works by setting up an idle timer.  Will
> run-with-idle-timer work if you give it a zero time-out?

Without looking at the code, it would be my guess that it would
currently run immediately after redisplay, whereas my suggestion for
jit-lock-defer-time=0 semantics would be that it be run immediately
before redisplay.

> And fontification of the visible portion will take time during which
> one still sees unfontified text, anyway.

Not if it happens before redisplay.  As I said, I think this would
make perfect sense for this setting.  If we want to differentiate for
some reason between immediately before and immediately after
redisplay, it would also be possible to use a negative value for "just
before redisplay" and 0 for "just after redisplay".

It would possibly make sense to implement this distinction in the
context of run-with-idle-timer, and then let jit-lock-defer-time just
use it by defaulting to -1.

Again: I have not looked at the code.  It just appears to me that this
would seem sensible behavior, and it would be nice to have an option
to tell jit-lock not to bother fontifying stuff unless it is actually
going to display it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum