Subject: Re: bug#17392: 24.3.90; cursor blinks faster and faster

From: Michael Heerdegen <[email-masked]>
Date: Tue, 13 May 2014 18:04:14 +0200

Eli Zaretskii <[email-masked]> writes:

> The C level is definitely involved, because it is the one which
> actually runs the timers.  But is the C level involved in the bug?

Yes, that's what I wanted to say.

Before spending time in debugging, I studied the related lisp code in
frame.el and timer.el.  AFAICT, you can't explain what I see exclusively
by bugs in that code.

> The blink-cursor-start timers are added by blink-cursor-check, so
> perhaps the problem is there?  E.g., it doesn't check timer-idle-list,
> it only checks that blink-cursor-idle-timer is nil.
>
> The function blink-cursor-check is called from two places:
> post-command-hook and handle-focus-in (via focus-in-hook).  Could it
> be that in your scenario two timers are started due to this?

No, I'm quite sure that this is not the case.  Whenever an idle blinking
timer is started, it is immediately bound to `blink-cursor-idle-timer'.
And `blink-cursor-idle-timer' is only reset to nil directly after
canceling the timer it was bound to.

But Eli, this advice:

  (advice-add 'timer-event-handler :before
              (lambda (timer)
                (unless (or (memq timer timer-list)
                            (memq timer timer-idle-list))
                  (message "This should not happen"))))

prints "This should not happen" for me.  I can easily reproduce this
message in emacs -Q.  Should that really be possible?  If not, isn't it
a clear sign that something's going wrong in keyboard.c?

Michael.