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

[Eli Zaretskii]

> Date: Wed, 7 Aug 2013 15:31:38 -0400
> From: Barry OReilly <gundaetiapo@gmail.com>
> Cc: 15045@debbugs.gnu.org
> 
> > 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?

I think the jit-lock you see is the result of the scrolling, not its
reason.

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

In the discussion that you cite at the beginning of this bug report, I
suggested a different approach to finding out the culprit, by using
the redisplay tracing facility.  Can you try that and post the
results?  It might give better clues.