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

[Barry OReilly]

> So it's "displayed at A" then "displayed at B" then "displayed at A
> again"? what happens between each one of those 3 displays?

No. A, B, and C are backtraces. Specifically, the backtraces printed
when goto-char went to the offending position at the beginning of the
comment block. I don't know which of the three is the one I see
actually displayed. The timestamps are too close together for me to be
certain.

I'm interested to see if I get more empty backtraces at the next
reproduction. I don't know what they could mean.

> If "nothing", then I suspect there's something like a `sit-for'
> somewhere that causes a redisplay in the middle of the command (i.e.
> in the middle of a save-excursion).

Ahh, I didn't know about sit-for. It might explain what I'm seeing.

I added a debug statement to Fredisplay. In a simple run (no
reproduction of the bug yet), I get a few of these:

2013-08-07T15:18:09.576922000|pid:11494|tid:47776720943360|dispnew.c|5822|
DEBUG: redisplay
  redisplay()
  sit-for(0)
  jit-lock-deferred-fontify()
  apply(jit-lock-deferred-fontify nil)
  byte-code("rÁÂHÃH\"ˆ)Á‡" [timer apply 5 6] 4)
  timer-event-handler([t 0 0 10000 t jit-lock-deferred-fontify nil idle 0])

I don't suppose there are ways deferred jit lock would execute during
Semantic lexing?

Anyway, next time I see the bug, I expect I'll get better data.