bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#17392: 24.3.90; cursor blinks faster and faster


From: Michael Heerdegen
Subject: bug#17392: 24.3.90; cursor blinks faster and faster
Date: Tue, 13 May 2014 18:04:14 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.90 (gnu/linux)

Eli Zaretskii <eliz@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]