GNU bug report logs - #18856
24.4; *grep* output buffer not getting fontified when jit-lock-defer-time is used

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 18856 <at> debbugs.gnu.org, deng <at> randomsample.de
Subject: bug#18856: 24.4; *grep* output buffer not getting fontified when jit-lock-defer-time	is used
Date: Tue, 28 Oct 2014 15:01:46 -0400

>> IOW jit-lock-defer should use a non-idle timer for this case.
> But then how do we ensure the fontifications don't happen for as long
> as Emacs isn't idle?

Yes, that question did occur to me as well, but I didn't have an
immediate answer, so I decided to stay silent ;-)

> test idleness by hand inside the timer function?

I don't think we can really do that unless we can access the "time since
idleness started" rather than just whether Emacs is idle or not (which
it almost always is when running timer functions).

Another approach would be to cancel that timer from pre-command-hook.

>> Note that an alternative implementation of jit-lock-defer which only
>> defers when there is not input pending would supposedly not suffer from
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> You mean, when there _is_ input pending, right?

Of course, thanks for correcting me.

>> this problem since it wouldn't defer fontification in this case (of
>> course, that would suffer from the reverse problem that by failing to
>> defer fontification, the redisplay may not be able to keep up with
>> process output).
> Indeed, so what's the point of doing that?

To only defer fontification when we know "for sure" that the user is
waiting for further processing.  If jit-lock-defer-time is smaller than
the normal time between key presses, deferring fontification actually
increases the amount of work done by Emacs, since we end up doing
2 redisplays per command (once without fontification, plus another one
with fontification after jit-lock-defer-time passed), so for "normal"
use, it's more efficient not to defer.

BTW, another reason not to defer for process-output is that contrary to
key-commands, process-output is processed more efficiently if we receive
it in large chunks than in small chunks.  So if there's "pending process
output", it's OK to keep redisplaying with fontification, since it just
means that the next time we get to read the process output we'll get more
output, which we'll hence process more efficiently.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.