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: Wed, 18 Nov 2015 05:49:06 +0200 Message-ID: <83wptg9dcd.fsf@gnu.org> References: <83r3jpc2of.fsf@gnu.org> <87h9kkbz6k.fsf@russet.org.uk> <838u5wbmvu.fsf@gnu.org> <83ziyc9zs0.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1447818566 29005 80.91.229.3 (18 Nov 2015 03:49:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Nov 2015 03:49:26 +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 Wed Nov 18 04:49:17 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 1ZytkC-0005PQ-7V for ged-emacs-devel@m.gmane.org; Wed, 18 Nov 2015 04:49:16 +0100 Original-Received: from localhost ([::1]:33582 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZytkB-0000H0-Jb for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2015 22:49:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45913) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zytk7-0000Gu-Sf for emacs-devel@gnu.org; Tue, 17 Nov 2015 22:49:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zytk4-0006RD-N0 for emacs-devel@gnu.org; Tue, 17 Nov 2015 22:49:11 -0500 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:48060) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zytk4-0006R5-EX for emacs-devel@gnu.org; Tue, 17 Nov 2015 22:49:08 -0500 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NXZ00K00QUI5300@mtaout26.012.net.il> for emacs-devel@gnu.org; Wed, 18 Nov 2015 05:52:10 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NXZ00GQBS2YXQ50@mtaout26.012.net.il>; Wed, 18 Nov 2015 05:52:10 +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.182 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:194691 Archived-At: > From: Stefan Monnier > Cc: phillip.lord@russet.org.uk, emacs-devel@gnu.org > Date: Tue, 17 Nov 2015 21:52:49 -0500 > > > 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. So we could start the timer not in the command loop, but somewhere in the loop that waits for process output, perhaps. But if an idle timer is fine, I think Phillip already has everyuthing sorted out on a branch.