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

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

run-with-idle-timer vs. run-at-time


From: Stefan Möding
Subject: run-with-idle-timer vs. run-at-time
Date: Mon, 15 Feb 2021 20:12:09 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (darwin)

Hi!

I'm trying to understand the difference between these two timers:

(run-with-idle-timer 0 nil (lambda () (...)))

(run-at-time 0 nil (lambda () (...)))

I suspect there is a difference (see below) but I'm unable to come up with
an example where it actually makes a difference.  Does anybody have an idea
what condition could cause a different behavior?

I can see from the documentation that `run-with-idle-timer' runs when
Emacs is waiting for input.  But that also seems to be the case for
`run-at-time'.  Is there a way that `run-at-time' might run at a time
(earlier) when `run-with-idle-timer' would not?

Background:

I'm trying to use the `guess-language' package from MELPA (also see
https://github.com/tmalsburg/guess-language.el).  The package integrates
with flyspell to guess the language of the current paragraph and set the
spelling dictionary according to the language. The package maintainer has
implemented this asynchronously using the `run-at-time` function as
illustrated above.

In my setup certain buffers now cause a freeze and I have to C-g to get
back to work.  It's reproducible but due to my setup it's too complicated
to expect the package author to have a look (e.g. using
`gnus-dired-attach' to create a message buffer to send a file as
attachment will cause the freeze; flyspell is enabled for message-mode).
I suspect the timer triggers the code to early and Emacs hangs while
trying to talk to the `hunspell' process.

There doesn't seem to be any more blocking if I replace `run-at-time` with
`run-with-idle-timer' in the package code.  So there seems to be
a difference.  Now I'm trying to come up with an example that might help
the package maintainer to understand why `run-with-idle-timer' might be
a better alternative (if it is that way).

Thanks for any pointers!

-- 
Stefan



reply via email to

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