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: Tue, 12 May 2015 21:59:59 +0100 Message-ID: <87y4kth5ps.fsf@newcastle.ac.uk> References: <87fv746rd5.fsf@newcastle.ac.uk> <87617zl4kh.fsf@newcastle.ac.uk> <87h9rjhy8w.fsf@newcastle.ac.uk> <87oalqrgm7.fsf@newcastle.ac.uk> <87ioby3tdy.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1431464461 12113 80.91.229.3 (12 May 2015 21:01:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 May 2015 21:01:01 +0000 (UTC) Cc: Emacs-Devel devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 12 23:00:55 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 1YsHIJ-0005XL-K6 for ged-emacs-devel@m.gmane.org; Tue, 12 May 2015 23:00:51 +0200 Original-Received: from localhost ([::1]:45169 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsHIJ-000589-3B for ged-emacs-devel@m.gmane.org; Tue, 12 May 2015 17:00:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46153) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsHHn-00057y-0S for emacs-devel@gnu.org; Tue, 12 May 2015 17:00:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YsHHi-0000Ga-Gy for emacs-devel@gnu.org; Tue, 12 May 2015 17:00:18 -0400 Original-Received: from cheviot12.ncl.ac.uk ([128.240.234.12]:51244) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsHHi-0000G9-Bp for emacs-devel@gnu.org; Tue, 12 May 2015 17:00:14 -0400 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 1YsHHg-0004ab-B7; Tue, 12 May 2015 22:00:12 +0100 Original-Received: from cpc7-benw10-2-0-cust228.16-2.cable.virginm.net ([77.98.254.229] helo=localhost) by smtpauth.ncl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1YsHHe-0004MB-Vh; Tue, 12 May 2015 22:00:12 +0100 In-Reply-To: (Stefan Monnier's message of "Tue, 12 May 2015 16:15:35 -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.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:186469 Archived-At: Stefan Monnier writes: >>> Then maybe you could try a hack like: >>> >>> (with-current-buffer "*scratch*" >>> ) >>> (let ((buffer-undo-list)) >>> (undo-boundary)) ; Set last_undo_buffer. >> It doesn't unfortunately. > > Oh, indeed when buffer-undo-list, undo-boundary is a no-op, so you need > > (with-current-buffer "*scratch*" > ) > (let ((buffer-undo-list '(""))) > (undo-boundary)) ; Set last_undo_buffer. My fault for not being clear. AFAICT, undo-boundary does not set last_undo_buffer at all. I can't directly test this because I can't get to last_undo_buffer from lisp, but here is my test code. #+BEGIN_SRC emacs-lisp (defvar-local fix-test-on nil) (defvar fix-test-fudge t) (defun fix-test-after-change-function (&rest _) (when fix-test-on (with-current-buffer (get-buffer "*scratch*") (insert "a")) (when fix-test-fudge (let ((buffer-undo-list '(""))) (undo-boundary))))) (add-hook 'after-change-functions 'fix-test-after-change-function) #+END_SRC Setting `fix-test-on' to t still affects undo in the current-buffer. >> It is, and one that has been in Emacs for a long time. How wedded to >> keeping it are you? Would it be possible to optionalize? > > Not sure, Well I have a fork running without it (with some brutal commenting out), so I'll try running that as my daily emacs, and see if it crashes and how it behaves. I'm still trying to understand the reason behind the logic in the first place; unfortunately, the code seems to predate the earliest VC records. Thanks for the feedback, it's been as helpful as always. Phil