> Funnily enough, "weird" was the exact word I used in an email too. But then > I thought buffering up the timers to run later might be the most logical > thing to do, in the circumstances. Maybe it makes more sense than not > running the timers at all. After all, as I'm sure the documentation aught > to say, the timer will be repeated *as soon as possible* after REPEAT > seconds. The behaviour is consistent at that level. A very quick simple > test shows the behaviour seems consistent if the function run by the timer > cancels the timer, when the function is run later due to buffering up of > timers, in the scenario you describe.
I admit that the behavior is consistent in each and every sense. I'm not sure whether it's reasonable, though. It's better than not running the timers at all, admittedly. Nevertheless, I think that timers should not run more often than indicated by the repeat argument. The documentation is misleading in any case. It tells you that when Emacs is busy, timers might not run. It doesn't tell you that timers may trigger more frequently than requested when Emacs is idle. > I found that buffering up of timers also occurs under X, at least for popups > of the sort you get from File > Open Directory... Under X, timers are > buffered up when the mouse is within the popup (though they are run as you > go in/out of the Filter, Directory, Files and Selection areas). I'm not > sure why that needs to be so for this particular case though. I agree that one-shot timers are generally better. But when I tried to implement a one-shot timer for delayed autoselection, it occasionally didn't trigger for some reason. Maybe I should give it another try. > You learn something every day. At least, I do about Emacs. _______________________________________________ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
