bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: 20404@debbugs.gnu.org
> Date: Thu, 23 Apr 2015 11:04:43 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > And here's why: _any_ command that goes through
> > execute-extended-command will run this code:
> >
> >             (when suggest-key-bindings
> >               (sit-for (cond
> >                         ((zerop (length (current-message))) 0)
> >                         ((numberp suggest-key-bindings) 
> > suggest-key-bindings)
> >                         (t 2))))))
> >
> > The default value of suggest-key-bindings is t, so this means we
> > _always_ sit-for 2 seconds, unless the echo area shows nothing (a rare
> > situation in Emacs).  When Emacs is parked inside sit-for, it doesn't
> > become idle, I think for good reasons.  So the idle timers will not
> > run until those 2 sec have expired, or some input becomes available.
> 
> Oh, yes, this explains things.

This problem doesn't exist in Emacs 24.5, it only happens on master.
And the reason seems to be the change in execute-extended-command:
Emacs 24 only calls sit-for when the command actually _has_ a key
binding:

    (when binding
      ;; But first wait, and skip the message if there is input.
      (let* ((waited
              ;; If this command displayed something in the echo area;
              ;; wait a few seconds, then display our suggestion message.
              (sit-for (cond
                        ((zerop (length (current-message))) 0)
                        ((numberp suggest-key-bindings) suggest-key-bindings)
                        (t 2)))))

On master, we wait unconditionally (and then wait some more if we
actually show the suggested key binding, but that happens only once
per given command).

So perhaps some small change there, which removes this unnecessary
unconditional wait whenever possible could solve the issue with
jit-lock-defer-time and other similar idle timers.

> Maybe such sticky messages could be shown in the `header-line' and then
> be removed by a timer.  But of course, what should one do if the
> header-line is already in use?

And in addition, this will cause an unpleasant redisplay of the
current window, something that display in the echo area avoids.

> But how does that explain the occassionally non-fontified compile
> buffers I get during package upgrades/installs?  Those don't go through
> `execute-extended-command'.  But compile.el has some own `sit-for'
> invocations that might delay timers.

Yes, something similar.  If you can reproduce these problems at will,
I can tell how to figure out which code caused the delay, similarly to
what I did to figure out the problem with execute-extended-command.