From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Calling Lisp from undo.c's record_* functions Date: Tue, 17 Nov 2015 21:44:31 +0200 Message-ID: <83ziyc9zs0.fsf@gnu.org> References: <83r3jpc2of.fsf@gnu.org> <87h9kkbz6k.fsf@russet.org.uk> <838u5wbmvu.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1447789502 16377 80.91.229.3 (17 Nov 2015 19:45:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 19:45:02 +0000 (UTC) Cc: emacs-devel@gnu.org, phillip.lord@russet.org.uk To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 17 20:44:53 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 1ZymBO-0005YT-IZ for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2015 20:44:50 +0100 Original-Received: from localhost ([::1]:60418 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZymBN-0005OZ-RJ for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2015 14:44:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52049) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZymBA-0005OI-Rr for emacs-devel@gnu.org; Tue, 17 Nov 2015 14:44:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZymB7-0003ye-L4 for emacs-devel@gnu.org; Tue, 17 Nov 2015 14:44:36 -0500 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:40422) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZymB7-0003ya-Cz for emacs-devel@gnu.org; Tue, 17 Nov 2015 14:44:33 -0500 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NXZ00K004Z6WA00@mtaout28.012.net.il> for emacs-devel@gnu.org; Tue, 17 Nov 2015 21:43:26 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NXZ00LF15GD3U10@mtaout28.012.net.il>; Tue, 17 Nov 2015 21:43:26 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.184 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:194666 Archived-At: > 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? 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?