From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Calling Lisp from undo.c's record_* functions Date: Tue, 17 Nov 2015 21:52:49 -0500 Message-ID: References: <83r3jpc2of.fsf@gnu.org> <87h9kkbz6k.fsf@russet.org.uk> <838u5wbmvu.fsf@gnu.org> <83ziyc9zs0.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447815208 14856 80.91.229.3 (18 Nov 2015 02:53:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Nov 2015 02:53:28 +0000 (UTC) Cc: emacs-devel@gnu.org, phillip.lord@russet.org.uk To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 18 03:53:20 2015 Return-path: Envelope-to: ged-emacs-devel@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 1Zysrz-0007OO-3V for ged-emacs-devel@m.gmane.org; Wed, 18 Nov 2015 03:53:15 +0100 Original-Received: from localhost ([::1]:33437 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zysry-0007aw-Aw for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2015 21:53:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58393) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zysrk-0007an-0R for emacs-devel@gnu.org; Tue, 17 Nov 2015 21:53:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zysrf-00006r-WE for emacs-devel@gnu.org; Tue, 17 Nov 2015 21:52:59 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:55233) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zysrf-00006n-RX; Tue, 17 Nov 2015 21:52:55 -0500 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id tAI2qsp7007101; Tue, 17 Nov 2015 21:52:54 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id 10D1E66157; Tue, 17 Nov 2015 21:52:49 -0500 (EST) In-Reply-To: <83ziyc9zs0.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 17 Nov 2015 21:44:31 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5493=0 X-NAI-Spam-Version: 2.3.0.9418 : core <5493> : inlines <4006> : streams <1539883> : uri <2084886> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:194687 Archived-At: >> > Would it work to have a non-idle timer that is started once at >> > startup, and then never shut down, and have its job be put on some >> > list that the timer will examine? >> I ruled that out early on in the design cycle because I think it's wrong >> for an application to have such constant background activity. > OK, but then the same considerations should prohibit using an idle > timer, no? No. The idle timer won't keep firing while Emacs stays idle. > How about the following idea: we don't start the timer from > run_undoable_change; instead, we set a flag there that will be checked > by the command loop when it finishes execution of a command, and the > call to start the timer will be made then? We don't really need to > attempt to start the timer for each and every change of every buffer, > do we? That would work similarly to an idle timer, so yes, that would be OK (tho an idle timer would be simpler). It suffers from the same problem as the idle timer: if there's no user interaction but there's continued process output, we'll fail to re-run the undo-auto-timer after the first N seconds of idleness. Nothing too serious (it's still better than what we have now anyway), tho. Stefan