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

[Eli Zaretskii]

> Cc: address@hidden
> From: David Kastrup <address@hidden>
> Date: Wed, 27 Apr 2005 11:43:01 +0200
> 
> We are talking about the situation where the input is coming in faster
> than Emacs can process it.

See, we don't really know that.  Whether this is true or not, depends
on several unknown factors, like the rate of keyboard auto-repeat on
the user's machine vs the time it takes Emacs on that machine, with
that CPU and display type/toolkit to perform redisplay.

In my experience, movement with C-n gives Emacs enough time to update
the display.

> In that case it will refrain from updating the display.  The
> question is whether it should also refrain from fontification.
> 
> Currently it doesn't.

Are you sure?  Fontification is a side effect of redisplay, so if
redisplay is not entered, I think there will be no fontification.

> > So when you are saying ``before redisplay'', what exactly do you
> > mean?
> 
> Before material actually gets transferred to the screen.

That's way _after_ almost all expensive portions of redisplay were
done.  Getting material to the screen, especially when motion was with
C-n, is very fast; most of the time it takes to update the display is
spent calculating what should be on the screen and finding the optimal
way of updating it.  So having such an option will not help alleviate
the problem that started this thread: how to make C-n fast as if
font-lock were not in effect.

jit-lock-defer-time non-nil works by disabling fontification
altogether until Emacs is idle.  If fontification is not disabled, you
yourself explained that vertical-motion _must_ fontify to keep its
calculations accurate.