Thanks for the report, and THANK YOU THANK YOU for solving the
problem as well. I have seen this reported, but had no idea what was
The reason for the delete/recreate was because older versions of
Emacs would auto-delete the idle timer after it fired once, and the
delete was needed to make sure there was only one timer on versions
that didn't auto-delete them.
Or something like that. It's been a long time since I wrote the
speedbar timer code which this was modeled after.
I will update CEDET CVS tonight.
>>> "Suraj Acharya" <sacharya@...> seems to think that:
>I was trying out a recent build of windows CVS emacs when I noticed
>that the semantic-idle timer was eating away a lot of CPU when emacs
>I managed to trace the problem down to a change in timer.el on Aug 20:
>This change affects the behavior of idle timers created while emacs is
>idle. If emacs has already been idle for the idle period of this timer
>when this timer was created, then the timer is run immediately. Before
>this change emacs would run this timer only after the idle period.
>(I hope this makes some sense.)
>The upshot is that because semantic-idle-scheduler-function destroys
>the old timer on entry and then creates new one just before it quits,
>emacs keeps calling the new timer right away after it has been idle
>for semantic-idle-scheduler-idle-time seconds.
>I'm not sure why semantic-idle-scheduler-function does this trick of
>destroying and creating the timer. I tried removing those calls and
>things seem to work fine so far. Any ideas on what the right solution
>to this problem is?
[ ... ]
Eric Ludlam: zappo@..., eric@...
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org