GNU bug report logs - #17392
24.3.90; cursor blinks faster and faster

Previous Next

Full log

View this message in rfc822 format

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17392 <at> debbugs.gnu.org
Subject: bug#17392: 24.3.90; cursor blinks faster and faster
Date: Tue, 13 May 2014 18:04:14 +0200

Eli Zaretskii <eliz <at> gnu.org> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.