From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#12447: 24.1.50; Stuck in garbage collection on OS X Date: Thu, 20 Sep 2012 19:01:20 +0300 Message-ID: <83ehlwznsf.fsf@gnu.org> References: <505598C8.8070904@yandex.ru> <834nmys1ht.fsf@gnu.org> <5055AD8E.5020309@yandex.ru> <83zk4qqj4d.fsf@gnu.org> <5055C0EB.3040908@yandex.ru> <83wqzuqgzr.fsf@gnu.org> <5055D34F.1040800@yandex.ru> <83txuyqdtv.fsf@gnu.org> <5055E16E.1070604@yandex.ru> <83sjaiqaqb.fsf@gnu.org> <5055F69B.4020004@yandex.ru> <837grr1idg.fsf@gnu.org> <5059115B.8010407@yandex.ru> <83txuuzpqo.fsf@gnu.org> <5059965F.5030708@yandex.ru> <83obl2yr19.fsf@gnu.org> <5059F10C.6070806@yandex.ru> <83ipbaynku.fsf@gnu.org> <87a9wlz6e4.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1348156964 20848 80.91.229.3 (20 Sep 2012 16:02:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Sep 2012 16:02:44 +0000 (UTC) Cc: 12447@debbugs.gnu.org, hanche@math.ntnu.no, dgutov@yandex.ru To: Chong Yidong Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 20 18:02:48 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TEjDC-000817-4a for geb-bug-gnu-emacs@m.gmane.org; Thu, 20 Sep 2012 18:02:46 +0200 Original-Received: from localhost ([::1]:52797 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEjD7-0007ic-R4 for geb-bug-gnu-emacs@m.gmane.org; Thu, 20 Sep 2012 12:02:41 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51568) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEjD0-0007iH-F3 for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 12:02:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEjCw-0002XJ-8H for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 12:02:34 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35829) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEjCw-0002X8-4j for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 12:02:30 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TEjEP-0004gr-I7 for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 12:04:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Sep 2012 16:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12447 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12447-submit@debbugs.gnu.org id=B12447.134815698817967 (code B ref 12447); Thu, 20 Sep 2012 16:04:01 +0000 Original-Received: (at 12447) by debbugs.gnu.org; 20 Sep 2012 16:03:08 +0000 Original-Received: from localhost ([127.0.0.1]:45375 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEjDX-0004fj-Pg for submit@debbugs.gnu.org; Thu, 20 Sep 2012 12:03:08 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:64296) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEjDU-0004fZ-Ql for 12447@debbugs.gnu.org; Thu, 20 Sep 2012 12:03:06 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MAN00500OENP800@a-mtaout22.012.net.il> for 12447@debbugs.gnu.org; Thu, 20 Sep 2012 19:01:06 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MAN005IVOHTKQ30@a-mtaout22.012.net.il>; Thu, 20 Sep 2012 19:01:06 +0300 (IDT) In-reply-to: <87a9wlz6e4.fsf@gnu.org> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:64644 Archived-At: > From: Chong Yidong > Cc: Dmitry Gutov , hanche@math.ntnu.no, 12447@debbugs.gnu.org > Date: Thu, 20 Sep 2012 12:04:51 +0800 > > Eli Zaretskii writes: > > >> Date: Wed, 19 Sep 2012 20:21:32 +0400 > >> From: Dmitry Gutov > >> 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.