bug#24585: 25.1; avoid hack in ggtags.el to run compilation-auto-jump timer

[Stefan Monnier]

>> IIUC this patch just changes the ordering for same-time timers.
>> Relying on either ordering is itself a hack.  We need a better solution.
> If you eval (progn (run-with-timer 0 ...)  ; timer 1
>                    (run-with-timer 0 ...)) ; timer 2
> you expect timer 1 to be triggered first, no?

Not really.  I think any code which relies on such a property will
sooner suffer.

>> What are those two timers whose relative execution order matters?
>> Why do they care in which order they're run?
> The first timer is compilation-auto-jump which is installed (by compile)
> at the start of compilation.
> The second timer is a cleanup timer which is installed (by ggtags) when
> compilation finishes and there is 0 or 1 match.
> The second timer kills the buffer (among other things) that the first
> timer depends on.

So we can fix the bug by making the timer's code check if the buffer is
still live?


        Stefan