From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@newcastle.ac.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: disabling undo boundaries Date: Mon, 11 May 2015 17:31:27 +0100 Message-ID: <87h9rjhy8w.fsf@newcastle.ac.uk> References: <87fv746rd5.fsf@newcastle.ac.uk> <87617zl4kh.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1431361905 5740 80.91.229.3 (11 May 2015 16:31:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 May 2015 16:31:45 +0000 (UTC) Cc: Emacs-Devel devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 11 18:31:40 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 1YrqcF-0007KY-FC for ged-emacs-devel@m.gmane.org; Mon, 11 May 2015 18:31:39 +0200 Original-Received: from localhost ([::1]:38716 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrqcE-0001p3-O8 for ged-emacs-devel@m.gmane.org; Mon, 11 May 2015 12:31:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37020) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrqcB-0001oL-3f for emacs-devel@gnu.org; Mon, 11 May 2015 12:31:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yrqc5-0000B4-2F for emacs-devel@gnu.org; Mon, 11 May 2015 12:31:35 -0400 Original-Received: from cheviot22.ncl.ac.uk ([128.240.234.22]:33998) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yrqc4-0000Ae-QL for emacs-devel@gnu.org; Mon, 11 May 2015 12:31:29 -0400 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 1Yrqc4-00077U-Cx; Mon, 11 May 2015 17:31:28 +0100 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 1Yrqc3-0006tS-Ql; Mon, 11 May 2015 17:31:27 +0100 In-Reply-To: (Stefan Monnier's message of "Mon, 11 May 2015 10:45:49 -0400") 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:186419 Archived-At: Stefan Monnier writes: >> The problem seems to come from here in record_point, in undo.c > >> if ((current_buffer != last_undo_buffer) >> /* Don't call Fundo_boundary for the first change. Otherwise we >> risk overwriting last_boundary_position in Fundo_boundary with >> PT of the current buffer and as a consequence not insert an >> undo boundary because last_boundary_position will equal pt in >> the test at the end of the present function (Bug#731). */ >> && (MODIFF > SAVE_MODIFF)) >> Fundo_boundary (); >> last_undo_buffer = current_buffer; > > Oh, I think you're right, this is even more likely the reason for > those boundaries. I'm getting slower better at reading Emacs source code:-) I really need to bite the bullet and learn C. >> The best thing that I can think of at the moment is to use >> post-command-hook to clean up the excessive undo-boundaries, but I am >> not sure how I am going to work out which ones are "real" and which ones >> not. The obvious solution (delete all those adding since the last >> command) will fail for both self-insert-command's logic and anywhere >> else that undo-boundary has been explicitly called. > > Indeed, removing those boundaries after the fact seems > difficult/tricky/risky. > > I'm not sure exactly what are your design constraints, I am trying to address a bug in lentic (available in all good repositories!). Lentic picks up the change in one buffer on the a-c-f and percolates it too another (or potentially any number of others). > but I can see a few alternatives: - disable undo in the "other buffer" > (*scratch* in your example, tho I suspect it's a different buffer in > your real case). This fails for me, unfortunately, the user might want to undo in the other buffer. A priori, though, it seems to be a nice idea. I tried this code for instance: #+BEGIN_SRC emacs-lisp (defvar-local fix-test-on nil) (defun fix-test-after-change-function (&rest _) (when fix-test-on (let ( (undo-inhibit-record-point t) ) (with-current-buffer (get-buffer "*scratch*") (insert "a"))))) (add-hook 'after-change-functions 'fix-test-after-change-function) #+END_SRC And that doesn't have the problem because the inhibit stops record_point from ever setting the undo_boundary. > - delay the modification of the other buffer (e.g. record in a-c-f the > boundaries of the affected text, and process them later from > post-command-hook). Not sure if this would really help. Unfortunately that wont work since there there can be many changes on a-c-f for a single p-c-h call. So, I'd have to amalgamate all the changes. > - change your a-c-f so it records the buffer-undo-list at the beginning, > and it removes the added boundary (if any) at the end. The a-c-f doesn't work, unfortunately because the nil boundary is not present till sometime after the a-c-f has been called (when? not sure). I did think of doing this with the pre/post-command-hook -- so, take the car of the b-u-l on the pre-c-h, then on the post-c-h, scan till I get to the old car and delete all nils placed there. I can see a few problems with this. First, it will also remove any undo-boundaries added by explict calls to undo-boundary; perhaps not a huge problem as there do not appear to be that many of them in the lisp code base. Second, it's still not going to work for self-insert-command because each of these are independent commands. Third, I seem to be reimplementing the undo system which feels ugly. Still, at the moment, this appears to be my only way forward. Phil