From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Should `cancel-timer' use `delete' instead of `delq'? Date: Wed, 6 Sep 2006 08:27:24 -0700 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1157556522 31836 80.91.229.2 (6 Sep 2006 15:28:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 6 Sep 2006 15:28:42 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 06 17:28:39 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GKzJv-0006MJ-OF for ged-emacs-devel@m.gmane.org; Wed, 06 Sep 2006 17:28:10 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GKzJu-0004tc-Uv for ged-emacs-devel@m.gmane.org; Wed, 06 Sep 2006 11:28:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GKzJK-0004ZO-7g for emacs-devel@gnu.org; Wed, 06 Sep 2006 11:27:30 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GKzJH-0004SV-66 for emacs-devel@gnu.org; Wed, 06 Sep 2006 11:27:29 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GKzJG-0004SK-Vf for emacs-devel@gnu.org; Wed, 06 Sep 2006 11:27:26 -0400 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1GKzJR-0000rh-I2 for emacs-devel@gnu.org; Wed, 06 Sep 2006 11:27:37 -0400 Original-Received: from rgmsgw01.us.oracle.com (rgmsgw01.us.oracle.com [138.1.186.51]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k86FRPfU002736 for ; Wed, 6 Sep 2006 10:27:25 -0500 Original-Received: from dradamslap (dradams-lap.us.oracle.com [130.35.177.126]) by rgmsgw01.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k86FROYZ013000 for ; Wed, 6 Sep 2006 09:27:24 -0600 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:59452 Archived-At: > Well, I think that's exactly what I used in my defvar (after > having been bitten once), so I could henceforth re-eval it > ("abnormally") without worry or forethought. In any case, the > "traditional" way to do that is apparently to use > `define-minor-mode'... The traditional example I showed is not exempt from the OP. When you re-evaluate the defvar with C-M-x, the timer var is forcefully reset to nil, thus potentially forgetting a running timer, which then becomes again difficult to stop. Maybe you did realize that, but I got the feeling that you thought it didn't suffer from this problem. I did realize that. I was attempting irony... And the same thing could/would happen if you use `timer-create'. The problem is not how you define/create your timer, but simply the fact that if you "forget" your timer object, it'll still be active as long as it's in the timer-list. One way to "solve" this problem is to change C-M-x so that in the case the variable's current value is a timer, it first cancels it, before resetting the var. Similarly to my "recent" patch which cancels timers when unloading a package. Yes. That's similar to what I proposed via a macro (to do the same thing). If the first-cancel-then-define part is all that would be done, then your suggestion is better. If more might be done (the activation and toggle-command options I suggested), then a macro could be better. Before this is laid to rest, let me request one more time that at least some mention be made of this in the Elisp manual - in some form or other, whether it's mentioned as a potential problem or whether some particular practice/guideline is suggested/recommended. If nothing else, it might be useful to point out that list `timer-idle-list' is what controls whether an idle timer is active (similarly, `timer-list'), so users will better understand that their defvar or whatever is not the only pointer to the timer object. This may be obvious to some, but I'm sure it is not obvious to some others. IOW, even if `cancel-timer' needs to be handed a timer object (which you might not have a handle for), you can always, as a last resort, delete your timers by hand from `timer(-idle)-list', assuming that you can recognize them (that is, you can reconstruct the list without them). Of course, someone bitten by this pitfall and desperate to cancel timers will examine the code of `cancel-timer' and find this out anyway, but foreknowledge of this wouldn't hurt.