> Cc: emacs-devel@gnu.org > From: David Kastrup <[EMAIL PROTECTED]> > Date: Wed, 27 Apr 2005 00:57:05 +0200 > > 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.
I'm not sure what that means. You _are_ aware that, when you scroll thru text with C-n or C-v, there's almost nothing going on in Emacs _except_ redisplay, yes? That is, all C-n does is move point one line; the rest is redisplay's job, including fontification. (The single most important new aspect of JIT lock as opposed to the old lazy-lock and its ilk was that JIT lock uses special hooks of the display engine, whereas the old, pre-v21 redisplay didn't have such hooks, and so lazy-lock needed to jump through the hoops to hook into every possible method of changing the displayed text.) So when you are saying ``before redisplay'', what exactly do you mean? Redisplay begins by computing the ``desired glyph matrix'', which is an internal representation of what should be on the screen; surely, before this happens, there's no way we could fontify the right portion of the text, since we have no idea what that portion is. > > And fontification of the visible portion will take time during which > > one still sees unfontified text, anyway. > > Not if it happens before 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. Idle timers run when Emacs is idle, which by definition is _after_ redisplay did its job. So I think you are talking about some nw mechanism, which has nothing to do with how jit-lock-defer-time works now. > Again: I have not looked at the code. Well, perhaps you should. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
