From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Madhu Newsgroups: gmane.emacs.devel Subject: Re: undo-auto--undoable-change infloop Date: Wed, 21 Sep 2022 18:58:08 +0530 Message-ID: References: <87o7xc1qbh.fsf@web.de> <831qu8dqrx.fsf@gnu.org> <87bktbciup.fsf@web.de> <875yjfo105.fsf@web.de> <87fsii0vvp.fsf@web.de> <87zgge3vzv.fsf@web.de> <87y1vwq0su.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36935"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Cancel-Lock: sha1:KYItqY/ig9AiA2GCe8uOENjc2O8= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 21 16:08:04 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ob0OS-0009QD-0J for ged-emacs-devel@m.gmane-mx.org; Wed, 21 Sep 2022 16:08:04 +0200 Original-Received: from localhost ([::1]:47250 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ob0OQ-0003e6-UI for ged-emacs-devel@m.gmane-mx.org; Wed, 21 Sep 2022 10:08:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46574) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oazm7-0003SX-4U for emacs-devel@gnu.org; Wed, 21 Sep 2022 09:28:29 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:56966) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oazm4-0005P0-Oa for emacs-devel@gnu.org; Wed, 21 Sep 2022 09:28:26 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1oazm2-0008B7-OQ for emacs-devel@gnu.org; Wed, 21 Sep 2022 15:28:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 21 Sep 2022 10:03:39 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:295914 Archived-At: * Michael Heerdegen <87y1vwq0su.fsf @web.de> : Wrote on Wed, 10 Aug 2022 04:39:45 +0200: > Stefan Monnier writes: > >> But I think you can `cancel-timer` before `timer-activate`, which will >> make sure it's not in the list any more. > > That solution also came to my mind. Wastes a lot of time, though. The > `timer-list' is traversed 3 times: First, to find the timer to delete > it, second to test if it's already present when trying to add it (your > change), third, to sort it in at the right position (though I don't > understand why that is necessary). The list is probably never that > large so that it would matter much. I didn't spot a bug report but I see this commit: * commit eb7fe81e6db8d630521098a728713e10c9d59c74 |Author: Stefan Monnier |AuthorDate: Fri Aug 5 10:38:59 2022 -0400 |Commit: Stefan Monnier |CommitDate: Fri Aug 5 10:38:59 2022 -0400 | | timer.el: Avoid repeated timers | | https://mail.gnu.org/archive/html/emacs-devel/2022-07/msg01127.html | points out that end-users can get bitten by this, accidentally | calling `timer-activate` on an already activated timer. | | * lisp/emacs-lisp/timer.el (timer--activate): Signal an error if we try | to re-add a timer that's already on the timer-list. FYI I thought I had a valid use case for calling timer--activate on an already active timer. ``` (defvar $jps-reader-reset-interval 10) (defvar $current-search-timer (run-with-timer $jps-reader-reset-interval nil (lambda () (let ((orig $current-search-string)) (setq $current-search-string "") (let (message-log-max) (message "timer: reset %s to %s" orig $current-search-string)))))) (defun respool () (progn ;;(find $current-search-timer timer-list) (setf (timer--time $current-search-timer) (time-add (seconds-to-time jps-reader-reset-interval) (current-time))) (timer-activate $current-search-timer))) ``` The idea was to handle a "mode" where keystrokes would enter characters in a "search string". the "mode" would timeout after a 10 seconds. If a new character of the "search string" is read within the timeout period, the timer is renewed ("respooled"). If a non "search string" character is read, then the timer is cancelled and the "mode" exits. After this commit the last line of respool has to look like (timer-activate $current-search-timer nil (cancel-timer-internal $current-search-timer)) Which uses an internal function, but I thought my timer-activate was legitimate to extend the timer. Maybe I should have approached the problem differently?