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 12:46:38 +0100 Message-ID: <87617zl4kh.fsf@newcastle.ac.uk> References: <87fv746rd5.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1431344827 29535 80.91.229.3 (11 May 2015 11:47:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 May 2015 11:47:07 +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 13:47:07 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 1YrmAp-0000zG-LM for ged-emacs-devel@m.gmane.org; Mon, 11 May 2015 13:47:03 +0200 Original-Received: from localhost ([::1]:36654 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrmAo-0003B1-HP for ged-emacs-devel@m.gmane.org; Mon, 11 May 2015 07:47:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44832) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrmAV-00037l-CB for emacs-devel@gnu.org; Mon, 11 May 2015 07:46:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YrmAS-00068o-5K for emacs-devel@gnu.org; Mon, 11 May 2015 07:46:43 -0400 Original-Received: from cheviot22.ncl.ac.uk ([128.240.234.22]:38511) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrmAR-00068R-SY for emacs-devel@gnu.org; Mon, 11 May 2015 07:46:40 -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 1YrmAQ-00035p-Fd; Mon, 11 May 2015 12:46:38 +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 1YrmAQ-00086v-KC; Mon, 11 May 2015 12:46:38 +0100 In-Reply-To: (Stefan Monnier's message of "Sun, 10 May 2015 21:42:51 -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:186396 Archived-At: Stefan Monnier writes: >> I am wondering why the "nil" undo-boundaries get inserted when I change >> *a different* buffer. This does not really make sense to me, and is >> causing breakage in my package. > > The 3 separate undo entries you're seeing are actually the "normal" > outcome (one undo-boundary per buffer-modifying command). > > self-insert-command has special ad-hoc code to try and merge sequences > of single-char insertions by removing the previous undo-boundary. > Which is why you normally only see a single undo entry. > > In your second case, I suspect that this ad-hoc code doesn't get to do > what it's intended to do, because it does not recognize the > undo-boundary that is candidate for removal as being "an undo-boundary > we've auto-inserted". So, self-insert-command thinks that this > undo-boundary may have been inserted by an explicit call to > `undo-boundary' at the end of the previous command, in which case it > should not be removed. > > The relevant code is in the remove_excessive_undo_boundaries function, > in src/cmds.c. Unfortunately, this is a general problem. Try enabling the a-c-f I sent previously, and then run "fill-paragraph" on an overly long line. With after-change-hook disabled.... Now is the winter of our discontent made glorious summer by the sun over york, whether it is M-q Now is the winter of our discontent made glorious summer by the sun over york, whether it is C-/ Now is the winter of our discontent made glorious summer by the sun over york, whether it is With after-change-hook enabled... Now is the winter of our discontent made glorious summer by the sun over york, whether it is M-q Now is the winter of our discontent made glorious summer by the sun over york, whether it is C-/ Now is the winter of our discontent made glorious summer by the sun over york, whether it is C-/ Now is the winter of our discontent made glorious summer by the sun over york, whether it is So, I have to do two undo's rather than one. 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; The a-c-f call causes an undo-able in scratch which means that "current-buffer != last_undo_buffer" succeeds, which forces an Fundo_boundary call on the NEXT call to record_point which is why I cannot see this boundary on a-c-f. 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. Better ideas welcome. Phil