From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@russet.org.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: Calling Lisp from undo.c's record_* functions Date: Tue, 17 Nov 2015 21:35:42 +0000 Message-ID: <8737w4mhqp.fsf@russet.org.uk> 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 1447796273 27893 80.91.229.3 (17 Nov 2015 21:37:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 21:37:53 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 17 22:37:44 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 1Zynwb-0004zr-Hu for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2015 22:37:41 +0100 Original-Received: from localhost ([::1]:60749 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zynwa-0006Zu-LW for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2015 16:37:40 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46333) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZynwV-0006WV-Rh for emacs-devel@gnu.org; Tue, 17 Nov 2015 16:37:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZynwV-0004Y2-39 for emacs-devel@gnu.org; Tue, 17 Nov 2015 16:37:35 -0500 Original-Received: from cheviot22.ncl.ac.uk ([128.240.234.22]:37131) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZynwP-0004V5-Pa; Tue, 17 Nov 2015 16:37:29 -0500 Original-Received: from smtpauth-vm.ncl.ac.uk ([10.8.233.129] helo=smtpauth.ncl.ac.uk) by cheviot22.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1ZynwP-0003Dc-Dw; Tue, 17 Nov 2015 21:37:29 +0000 Original-Received: from cpc6-benw10-2-0-cust45.gate.cable.virginm.net ([92.238.179.46] helo=localhost) by smtpauth.ncl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1ZynwP-00059u-5v; Tue, 17 Nov 2015 21:37:29 +0000 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/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 128.240.234.22 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:194670 Archived-At: Eli Zaretskii writes: >> From: Stefan Monnier >> Cc: phillip.lord@russet.org.uk (Phillip Lord), emacs-devel@gnu.org >> Date: Tue, 17 Nov 2015 11:51:25 -0500 >> >> > 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? Yep, pretty much. > 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 need the timer when the command loops is running. The command loop will add undo-boundaries. > We don't really need to attempt to start the timer for each and every > change of every buffer, do we? At the moment, we do, yes -- note that we actually only start the timer if one isn't already running. There are other solutions. We could just count the number of undoable events since the last command, and add a boundary once a threshold has been reached. Phil