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

[David Engster <deng@randomsample.de>]

martin rudalics writes:
>> In fact, I just understood another bug in speck-mode (which is similar
>> to flycheck). I sometimes had unwanted scrolls there, too, and I now saw
>> that those also happen at every full minute while typing.
>
> What precisely is the bug in speck-mode?  Is it that it doesn't restore
> `point' when input arrives?

The main problem is that speck narrows the buffer before calling
`accept-process-output'. If that happens while the
time-display-event-handler runs, you suddenly see a narrowed buffer,
which is soon widened again. Pretty scary.

It's quite easy to reproduce, since speck runs much longer than the
Semantic idle function. Here's a recipe:

- Put a bunch of text in the kill ring
- Create a new text buffer and activate speck
- Activate `display-time'
- At roughly XX:58, yank the text into the buffer and wait

Here's the backtrace from a `debug' call in `sit-for':

  sit-for(0)
  display-time-event-handler()
  apply(display-time-event-handler nil)
  byte-code("" [timer apply 5 6] 4)
  timer-event-handler([t 20997 5988 0 60 display-time-event-handler nil nil 0])
  accept-process-output(nil 0.01)
  speck-chunk()
  speck-multi-chunk()
  speck-chunks()
  speck-line()
  speck-window(t)
  speck-windows(t)
  apply(speck-windows t)
  byte-code("" [timer apply 5 6] 4)
  timer-event-handler([t 0 1 262453 nil speck-windows (t) idle 785000])

The fix would be to undo any narrowing and restore point before calling
`accept-process-output'.

-David