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: Wed, 27 May 2015 12:46:43 +0100 Message-ID: <878ucaqm3g.fsf@newcastle.ac.uk> References: <87fv746rd5.fsf@newcastle.ac.uk> <87ioby3tdy.fsf@newcastle.ac.uk> <87y4kth5ps.fsf@newcastle.ac.uk> <87sib0a3jr.fsf@newcastle.ac.uk> <871tiiowjw.fsf@newcastle.ac.uk> <87siaxk4dl.fsf@newcastle.ac.uk> <87iobsr6m2.fsf@newcastle.ac.uk> <87oalgaicm.fsf@newcastle.ac.uk> <87y4kkkzlo.fsf@newcastle.ac.uk> <87mw0zk7yp.fsf@newcastle.ac.uk> <87617mgp1b.fsf@newcastle.ac.uk> <871ti9ammc.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1432727248 19443 80.91.229.3 (27 May 2015 11:47:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 May 2015 11:47:28 +0000 (UTC) Cc: Emacs-Devel devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 27 13:47:23 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 1YxZnv-0002oj-43 for ged-emacs-devel@m.gmane.org; Wed, 27 May 2015 13:47:23 +0200 Original-Received: from localhost ([::1]:53236 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxZnu-0003bY-Ig for ged-emacs-devel@m.gmane.org; Wed, 27 May 2015 07:47:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57567) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxZnW-0003Oe-Gr for emacs-devel@gnu.org; Wed, 27 May 2015 07:47:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YxZnR-0005Xl-O2 for emacs-devel@gnu.org; Wed, 27 May 2015 07:46:58 -0400 Original-Received: from cheviot22.ncl.ac.uk ([128.240.234.22]:41474) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxZnR-0005Eh-IY for emacs-devel@gnu.org; Wed, 27 May 2015 07:46:53 -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 1YxZnI-00022Z-Fk; Wed, 27 May 2015 12:46:44 +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 1YxZnI-0004HF-Pr; Wed, 27 May 2015 12:46:44 +0100 In-Reply-To: <871ti9ammc.fsf@newcastle.ac.uk> (Phillip Lord's message of "Thu, 21 May 2015 18:03:55 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.0.0.0 (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:186864 Archived-At: Phillip Lord writes: > Stefan Monnier writes: >> Another approach would be for you to arrange such that your a-f-c uses >> self-insert-command rather than `insert' when cloning the insertion >> from a self-insert-command, but that's probably just as hard if not >> harder. > > That doesn't sound great to me either, as I have to behave quite > differently depending on the last-command. > > It seems to me, that you are not adverse to the idea of changing undo.c > to stop it putting boundaries in. Can I suggest a way forward? I will > carry on with my hacked Emacs with removed undo-boundaries in undo.c. I > can add the "undo-boundary to all changed buffers" using > post-command-hook. This will let me test everything makes sense and > works as expected, and I don't mind spending the effort, if emacs will > support it later. > > If you are prepared to implement the "add an undo-boundary to every > buffer thats changed" logic into undo.c/cmd.c, then we can do that once > the logic works. I would be willing to help with that, but my C > programming is very poor, and in practice, I'm likely to learn more than > I actually help. Actually, I have been thinking about this. What I worry about with this is that we may be adding the same form of heuristic into undo.c as the "insert an undo-boundary if the buffer has changed". And once is in the C layer it is effectively unfixable from lisp. The existing logic does not seem unsensible, but actually does not work in my (admitted niche) set of circumstances. So, it may be that simply removing the existing logic is the right thing to do! Phil