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 14:42:44 +0000 Message-ID: <87d1v8bsbf.fsf@russet.org.uk> References: <83r3jpc2of.fsf@gnu.org> <87h9kkbz6k.fsf@russet.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447771473 799 80.91.229.3 (17 Nov 2015 14:44:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 14:44:33 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 17 15:44:29 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 1ZyhUi-0002UG-I4 for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2015 15:44:28 +0100 Original-Received: from localhost ([::1]:58894 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyhUc-0000oi-CN for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2015 09:44:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52457) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyhTB-0007pA-M4 for emacs-devel@gnu.org; Tue, 17 Nov 2015 09:42:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZyhTA-00064A-Oe for emacs-devel@gnu.org; Tue, 17 Nov 2015 09:42:53 -0500 Original-Received: from cheviot12.ncl.ac.uk ([128.240.234.12]:55430) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyhT5-00061b-9T; Tue, 17 Nov 2015 09:42:47 -0500 Original-Received: from smtpauth-vm.ncl.ac.uk ([10.8.233.129] helo=smtpauth.ncl.ac.uk) by cheviot12.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1ZyhT3-0001aV-B2; Tue, 17 Nov 2015 14:42:45 +0000 Original-Received: from jangai.ncl.ac.uk ([10.66.67.223] helo=localhost) by smtpauth.ncl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1ZyhT3-0003mE-0z; Tue, 17 Nov 2015 14:42:45 +0000 In-Reply-To: (Stefan Monnier's message of "Tue, 17 Nov 2015 08:46:40 -0500") 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.12 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:194643 Archived-At: Stefan Monnier writes: >>>> My dilemma is: how to fix this cleanly and correctly? >>> Not sure what's the best solution, but the precise moment when >>> run_undoable_change is executed is not terribly important, so if we >>> could just move it to either before or after the "critical section", >>> then that would be a good solution. >> I'm not sure how I would identify the "critical section". > > The "critical section" is the span of code during which the buffer is > "being worked on" by the insertion function, so during this time, the > buffer shouldn't be modified by anyone else in any way: no Elisp code > should be run, no GC should take place. Assuming the documentation of undo.c is rigourously followed, then this should only be a problem for insert. All the others say "at the beginning of the command" or "about to happen". Only insertion says "before or after". Although, record_insert calls record_point which rather confuses me -- surely in record_insert can be after, so can record_point. In theory, therefore, we should already be safe? Or can the critical section be longer than a single function call to undo.c? Could the unsafe period cover several calls? There are only 7 calls to record_insert so changing the so record_insert is *always* before would be possible. Big change to make at this point in the release cycle. >> At one point, this function call was actually a hook >> (after-undoable-change-hook). Would this solve the problem? > > Nope, makes no difference. Ok. I'll finish my patch off this evening, hopefully. Phil