From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: disabling undo boundaries Date: Mon, 11 May 2015 15:30:33 -0400 Message-ID: References: <87fv746rd5.fsf@newcastle.ac.uk> <87617zl4kh.fsf@newcastle.ac.uk> <87h9rjhy8w.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1431372652 11790 80.91.229.3 (11 May 2015 19:30:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 May 2015 19:30:52 +0000 (UTC) Cc: Emacs-Devel devel To: phillip.lord@newcastle.ac.uk (Phillip Lord) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 11 21:30:45 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 1YrtPZ-0007Os-Kp for ged-emacs-devel@m.gmane.org; Mon, 11 May 2015 21:30:45 +0200 Original-Received: from localhost ([::1]:39384 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrtPZ-0005Ui-6R for ged-emacs-devel@m.gmane.org; Mon, 11 May 2015 15:30:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52543) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrtPU-0005UR-Gb for emacs-devel@gnu.org; Mon, 11 May 2015 15:30:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YrtPP-0001Sx-8k for emacs-devel@gnu.org; Mon, 11 May 2015 15:30:40 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:49661) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrtPO-0001Sg-NC for emacs-devel@gnu.org; Mon, 11 May 2015 15:30:35 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGvvdVRFpYts/2dsb2JhbAA3DoFFoW+BCIF1AQEEAVYjBQsLNBIUGA2IN6IRi3YWARRDg00Dg3AEo2OEBVM X-IPAS-Result: AgUFAGvvdVRFpYts/2dsb2JhbAA3DoFFoW+BCIF1AQEEAVYjBQsLNBIUGA2IN6IRi3YWARRDg00Dg3AEo2OEBVM X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="119201573" Original-Received: from 69-165-139-108.dsl.teksavvy.com (HELO pastel.home) ([69.165.139.108]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 May 2015 15:30:34 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id BC42D3450; Mon, 11 May 2015 15:30:33 -0400 (EDT) In-Reply-To: <87h9rjhy8w.fsf@newcastle.ac.uk> (Phillip Lord's message of "Mon, 11 May 2015 17:31:27 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:186433 Archived-At: >> 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. So, you're saying that the above let binding fixes your problem? Then, I guess it's a valid option as well. It sounds like an obscure work-around, so it probably deserves a clear comment. >> - 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. Amalgamate is exactly what I meant by "record the boundaries". It's a fairly common approach, typically you only track the beg/end enclosing boundaries. E.g. I use it in diff-mode to avoid modifying the buffer right in the middle of a-c-f, which tends to break all kinds of assumptions. >> - 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). That is weird. The code you quoted from record_point should be run "right away". Are you sure you didn't check in the wrong buffer by any chance? I'd expect something like (let ((old-ul buffer-undo-list)) (with-current-buffer "*scratch*" ) (and (consp buffer-undo-list) (eq (cdr buffer-undo-list) old-ul) (null (car buffer-undo-list)) (setq buffer-undo-list (cdr buffer-undo-list)))) to do the trick. Or, what am I missing? > 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. But at that point you won't know which undo-boundaries were added because of the buffer-switch and which were added for other reasons. > 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. Since `doyourthing' shouldn't touch the source buffer, the source buffer's undo-list has no reason to have a hand-added undo-boundary. Stefan