[Top][All Lists]

[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: Sun, 11 May 2014 13:09:30 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.90 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

> So I'm asking whether you are sure what you see is a real problem, and
> not some artifact of how you look for a problem.

No, I'm not sure.  And I didn't want to convince you, on the contrary, I
need help to find it out.  My knowledge of the C code is limited.

Here is what I do know for sure:  Evaluating

--8<---------------cut here---------------start------------->8---
  (defun provoke (&rest _)
    (run-with-idle-timer .001 nil
                         (lambda () (sit-for 2.)
                           (message "%s" (length timer-idle-list)))))
  (defadvice handle-switch-frame (after provoke activate)
--8<---------------cut here---------------end--------------->8---

and switching frames with M-TAB leads to a situation where multiple
timers running blink-cursor-start are present in timer-idle-list.  These
timers are all `equal', but not `eq' - they are different objects.

I advised all functions named timer-... to count the number of
_different_ timers running `blink-cursor-start' (those in
timer-idle-list, plus the one maybe bound to blink-cursor-idle-timer)
before and after the call to the function.  I can post the code if you

This count should always be <= 1, right?  With the advices, I was
interested in the first time when the count is > 1, i.e., when the state
switched from sane to pathological.

And I found that the count was > 1 for the first time after
`timer-event-handler' had been called (from C).  Before that call the
count had still been 1.  And I know why the count increased: namely because
the timer object that timer-event-handler was called with was not
present (referable) from the Lisp level at that point of time.  But
another (equal, but not eq) timer was present in timer-idle-list.

Due to lack of C knowledge, I can't interpret that result.  But it shows
that the C level is definitely involved, and the bug is not in timer.el,
at least, not only.

Summa summarum: no, I don't know if this `timer-event-handler' call from
C is unkosher, but it is the mechanism that leads to successive
additions of blink-cursor-start timers to timer-idle-list.


reply via email to

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