bug#15045: Point jumps inappropriately around time of Semantic lexing

[David Engster <deng@randomsample.de>]

Barry OReilly writes:
>>   timer-event-handler([t 20995 27860 0 60 display-time-event-handler nil nil 0])
>>   accept-process-output()
>>   semantic-c-lexer(2886 7946 nil nil)
>
> and
>
>>   timer-event-handler([t 20995 36800 0 60 display-time-event-handler nil nil 0])
>>   input-pending-p()
>>   semantic-c-lexer(2939 7944 nil nil)
>
> This is indeed a key finding.
>
> If arbitrary timers can execute during the lexer's call to
> accept-process-output or input-pending-p, then doesn't that mean
> jit-lock-deferred-fontify can run too?

Under certain circumstances I guess it could, but usually, deferred
jit-lock will happen after a keypress, and that would already make the
Semantic idle function quit.

> If removing timers' sit-for calls is the solution, then what's to
> become of jit-lock-deferred-fontify's call to sit-for?

That is not the solution, at least not in general. As I've written, I
think the correct fix is for Semantic to make sure we restore point
before calling `semantic-throw-on-input'. Or maybe we should do this in
`semantic-exit-on-input'; I'm not sure.

However, doing redisplay in timers is not nice. If it is not necessary,
like maybe in the time-display handler, then it should be removed.

> Doesn't deferred jit locking necessarily have to call redisplay?

I would think so, too.

-David