From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@russet.org.uk (Phillip Lord) Newsgroups: gmane.emacs.bugs Subject: bug#23632: 25.1.50; Gratuitous undo boundary in latex-insert-block Date: Thu, 02 Jun 2016 21:08:46 +0100 Message-ID: <87vb1rbbg1.fsf@russet.org.uk> References: <87lh2vo7s6.fsf@gmail.com> <87shx23830.fsf@gmail.com> <87wpmcwn13.fsf@russet.org.uk> <87wpm9q4z7.fsf@russet.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1464947008 25170 80.91.229.3 (3 Jun 2016 09:43:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 Jun 2016 09:43:28 +0000 (UTC) Cc: Chong Yidong , 23632@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 03 11:43:14 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1b8ldI-0004Gy-Vt for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 Jun 2016 11:43:13 +0200 Original-Received: from localhost ([::1]:53759 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8ldI-00036r-4d for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 Jun 2016 05:43:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38492) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8ld9-00034y-6w for bug-gnu-emacs@gnu.org; Fri, 03 Jun 2016 05:43:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b8ld8-0006Lo-42 for bug-gnu-emacs@gnu.org; Fri, 03 Jun 2016 05:43:03 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:40062) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8ld8-0006LY-0n for bug-gnu-emacs@gnu.org; Fri, 03 Jun 2016 05:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1b8ld7-0006le-QJ for bug-gnu-emacs@gnu.org; Fri, 03 Jun 2016 05:43:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: phillip.lord@russet.org.uk (Phillip Lord) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 Jun 2016 09:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23632 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 23632-submit@debbugs.gnu.org id=B23632.146494697326000 (code B ref 23632); Fri, 03 Jun 2016 09:43:01 +0000 Original-Received: (at 23632) by debbugs.gnu.org; 3 Jun 2016 09:42:53 +0000 Original-Received: from localhost ([127.0.0.1]:52399 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b8lcz-0006lI-7m for submit@debbugs.gnu.org; Fri, 03 Jun 2016 05:42:53 -0400 Original-Received: from cheviot12.ncl.ac.uk ([128.240.234.12]:37118) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b8lcx-0006l9-8l for 23632@debbugs.gnu.org; Fri, 03 Jun 2016 05:42:52 -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 1b8lcw-0007y7-9p; Fri, 03 Jun 2016 10:42:50 +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 1b8lcv-0006GP-Rg; Fri, 03 Jun 2016 10:42:49 +0100 In-Reply-To: (Stefan Monnier's message of "Wed, 01 Jun 2016 09:15:37 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.94 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:119006 Archived-At: Stefan Monnier writes: >> What worries me is that it just deals with the minibuffer. I wonder >> whether there are other circumstances where a recursive edit is going to >> break things. > > I guess we could introduce a new var (call it > `undo-auto-current-buffer-only' or `undo-auto-ignore-other-buffers' or > what have you) which packages could let-bind around recursive edits. > We could also change the minibuf.c code to bind this var, so you could > check the var instead of hard-coding (minibufferp) in your patch. > > The main use-case I can think of would be debug/edebug. > > This said, if the changes in other buffers are due to process-filters, > then they still should get an undo-boundary during > minibuffer/recursive edits. So maybe instead of "only push > undo-boundaries in current-buffer", we should have a variable holding > a list of buffers where we shouldn't push undo-boundaries (unless > they're the current-buffer). > > Or an alternative would be to do what Viper does (well, did): keep > pushing boundaries as before, but when we return from the minibuffer, > remove any boundaries that were inserted into the current-buffer's > undo-list during the recursive edit. What I dislike about this is that other packages are responsible for getting things right. What about this 1) undo-auto--undoably-changed-buffers becomes an alist ((0 . (buffers*)) (1 . (buffers*)) (2 . (buffers*))) where the key is the return of (recursion-depth) 2) undo-auto--boundaries operates only on buffers at the current-recursion-depth. Or, probably, at the current of greater recursion depth, to ensure that undo-buffers happens when a recursive edit exits. This way, process buffers will still get an undo-boundary if they change during the recursive edit. >> Incidentally, this is a nightmare to debug. Emacs needs to be able to >> write to standard out, so I could log without changing any buffers! > > What I do is to push to a variable, and then observe the var from M-x > ielm or some such. That's a good idea -- I've been doing the former, then using C-hv. Phil