bug#22287: 25.1.50; Sudden jumping point in buffer

[David Engster <deng@randomsample.de>]

Stefan-W. Hahn writes:
> If I see it right, then semantic-c-lexer will be called under save-excursion
> from semantic-idle-core-handler whenn called via timer-event-handler:
>
> ,----
> | "semantic-idle-core-handler" (0xffffcb50)
> | "semantic-idle-scheduler-function" (0xffffce08)
> | "apply" (0xffffce00)
> | "timer-event-handler" (0xffffcfc8)
> `----
>
> but when called from semanticdb-save-all-db-idle (I think) it will be called
> from semanticdb-save-db and
>
> ,----
> |     (semantic-exit-on-input 'semanticdb-idle-save
> |       (mapc (lambda (db)
> | 	      (semantic-throw-on-input 'semanticdb-idle-save)
> | 	      (semanticdb-save-db db t))
> | 	    semanticdb-database-list))
> `----
>
> therefore from within semantic-exit-on-input, which is a catch. And with my
> other observations I saw the catch exiting with moved point.
>
> This seems to explains, why a save-excursion around this works for me.
>
> I also tried a save-excursion around semantic-c-lexer and this seems to work
> too.
>
> So after all this: my opinion is that semantic-c-lexer is the problem.

That is some impressive sleuthing you did there. Thanks a lot!

The problem is that the `object-write' method for the semanticdb-table
class calls `semantic-fetch-tags'. I was completely unaware of
that. When the table is not up-to-date, it will re-parse the buffer and
call the lexer.

So yes, this has to be wrapped in a save-excursion. But more
importantly, I think we should not put semanticdb-save-all-db-idle in
the auto-save-hook. As a function meant for idle-time, it really has no
business there. My best guess is that Eric originally thought that the
auto-save-hook is only called during idle time. I'll look a bit more
into what this entails, and I'll apply a fix in the coming days.

Thanks again,
David