bug#12447: 24.1.50; Stuck in garbage collection on OS X

[Eli Zaretskii <eliz@gnu.org>]

> From: Chong Yidong <cyd@gnu.org>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  hanche@math.ntnu.no,  12447@debbugs.gnu.org
> Date: Thu, 20 Sep 2012 12:04:51 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Date: Wed, 19 Sep 2012 20:21:32 +0400
> >> From: Dmitry Gutov <dgutov@yandex.ru>
> >> CC: jan.h.d@swipnet.se, 12447@debbugs.gnu.org, hanche@math.ntnu.no
> >> 
> >> By the way, here's what run-with-idle-timer docstring says:
> >> "Perform an action the next time Emacs is idle for SECS seconds."
> >> 
> >> Shouldn't this mean that it should also pass DONT-WAIT nil?
> >
> > No, it just means no one considered the possibility that an idle timer
> > will re-invoke itself like that.  IOW, the doc string is inaccurate.
> 
> I'm not 100% sure this is merely a doc string problem.  In the face of
> ambiguity, we should try to choose the behavior that is least likely to
> lead to infloops in user code.

There's no infloop with my patch.  Assuming that no one comes with a
loop in a couple of days, I will install that, and this particular
issue will be gone.

In general, I think we should prefer solutions that allow Lisp
programmers or users do dumb things (and sometimes get dumb results),
without wedging Emacs.  Restricting what Lisp can do because someone
dumb could wedge Emacs runs a risk of punishing the innocent lot
because of a guilty (or dumb) few.

> When `run-with-idle-timer' is called from an idle timer, we could
> interpret it to mean "run the function the next time Emacs becomes idle
> for SECS seconds, not including the current period of idleness".

I could think of some legitimate uses of the current behavior, though.
For example, imagine an idle timer that gets run after 1 sec of
idleness, does something quick and simple, and then calls itself or
another time with a larger timeout value, at which time it will do
something different, perhaps more complex.  I see no reason to
forcibly prevent such use cases.

It is also in line with Emacs behavior since about forever.  The
possibility of an infloop was a side effect of another bugfix.  With
that possibility hopefully taken care of, we have no reason to change
old behavior, which evidently at least one external package relies
upon.