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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: deng@randomsample.de,  18856@debbugs.gnu.org
> 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).

Doesn't current-idle-time fit the bill?

> >> 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.

Sorry, you lost me.  When input is pending, what further processing is
the user waiting for?

And anyway, isn't running off an idle timer already an attempt to
defer when there's more input, i.e. Emacs is not idle?

> 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.

I don't think this is too high a price.  First, as Alain established,
what takes 90% of the time is not redisplay, but fontifications, and
those are run only once.  And second, the 2nd redisplay will only
redraw the portions that were fontified, not the entire window.  So
this is not "twice", but more like 1.2 times.

> 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.

Yes, I actually thought of disabling deferral when a process filter
runs.