From: phillip.lord@russet.org.uk (Phillip Lord)
To: Chong Yidong <cyd@gnu.org>
Cc: 23632@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
Subject: bug#23632: 25.1.50; Gratuitous undo boundary in latex-insert-block
Date: Tue, 31 May 2016 22:42:36 +0100 [thread overview]
Message-ID: <87wpm9q4z7.fsf@russet.org.uk> (raw)
In-Reply-To: <87wpmcwn13.fsf@russet.org.uk> (Phillip Lord's message of "Sun, 29 May 2016 22:51:36 +0100")
[-- Attachment #1: Type: text/plain, Size: 2082 bytes --]
phillip.lord@russet.org.uk (Phillip Lord) writes:
> Chong Yidong <cyd@gnu.org> writes:
>
>>> The attached patch, which gets rid of the undo boundary, seems to fix
>>> this:
>>
>> Actually, the previous patch does not DTRT: if you switch back to the
>> original buffer from the minibuffer, and make further editing changes,
>> those changes would get lost because buffer-undo-list is temporarily
>> rebound.
>>
>> Here is a different patch, which works by removing the undo boundary in
>> buffer-undo-list if there's one. It also tweaks HTML mode and Texinfo
>> mode, which have similar issues. It defines a new function
>> `undo-amalgamate', split off from `undo-auto-amalgamate', for
>> convenience.
>
>
> In and off itself, the patch seems fine, but my concern is that that the
> previous heuristic did the right thing, the new heuristic does not. If
> you've found three instances where it's causing a problem, then there
> will be others also.
>
> I'm not 100% sure why the old system didn't insert an undo-boundary.
> But, if we could solve this entirely in the undo system without changes
> to client code that would be nicer.
>
> Not sure how yet -- need a few days to think about it. Perhaps,
> suppressing the auto-boundary functionality when only the mini-buffer
> has changed.
I've debugged this now.
The problem, I think, is that latex-insert-block uses recursive editing
(via `completing-read', then `read-from-minibuffer') -- so the
minibuffer is edited, then the exit-minibuffer command runs, causing an
undo boundary to be added to minibuffer (correctly) but also to the
latex buffer because it has also changed.
The patch below seems to fix -- I need to test it out tomorrow in case
it has any other unexpected effects.
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.
Stefan, would welcome your opinion here.
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!
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Stop-mini-buffer-causing-undo-boundaries.patch --]
[-- Type: text/x-diff, Size: 1925 bytes --]
From 9116e7f00f90fb14857d21698b1e6870fcf98bbd Mon Sep 17 00:00:00 2001
From: Phillip Lord <phillip.lord@russet.org.uk>
Date: Mon, 30 May 2016 22:50:36 +0100
Subject: [PATCH] Stop mini-buffer causing undo boundaries
* lisp/simple.el (undo-auto--boundaries): Check whether minibuffer is
current, and if so limit undo-boundaries to it.
Addresses #23632
---
lisp/simple.el | 21 +++++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/lisp/simple.el b/lisp/simple.el
index c5aa292..788cbb2 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -2887,12 +2887,21 @@ undo-auto--boundaries
"Check recently changed buffers and add a boundary if necessary.
REASON describes the reason that the boundary is being added; see
`undo-last-boundary' for more information."
- (dolist (b undo-auto--undoably-changed-buffers)
- (when (buffer-live-p b)
- (with-current-buffer b
- (unless undo-auto-disable-boundaries
- (undo-auto--ensure-boundary cause)))))
- (setq undo-auto--undoably-changed-buffers nil))
+ ;; We treat the minibuffer specially, because some commands use the
+ ;; minibuffer after changing the buffer that they are launched
+ ;; from. Changes in the minibuffer force an undo-boundary in the
+ ;; launched buffer without this handling. (see bug #23632)
+ (if (minibufferp)
+ (progn
+ (undo-auto--ensure-boundary cause)
+ (setq undo-auto--undoably-changed-buffers
+ (delq (current-buffer) undo-auto--undoably-changed-buffers)))
+ (dolist (b undo-auto--undoably-changed-buffers)
+ (when (buffer-live-p b)
+ (with-current-buffer b
+ (unless undo-auto-disable-boundaries
+ (undo-auto--ensure-boundary cause)))))
+ (setq undo-auto--undoably-changed-buffers nil)))
(defun undo-auto--boundary-timer ()
"Timer which will run `undo--auto-boundary-timer'."
--
2.8.3
next prev parent reply other threads:[~2016-05-31 21:42 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-27 15:11 bug#23632: 25.1.50; Gratuitous undo boundary in latex-insert-block Chong Yidong
2016-05-28 8:22 ` Chong Yidong
2016-05-29 21:51 ` Phillip Lord
2016-05-31 21:42 ` Phillip Lord [this message]
2016-06-01 13:15 ` Stefan Monnier
2016-06-02 20:08 ` Phillip Lord
2016-06-03 13:00 ` Stefan Monnier
2016-06-03 16:13 ` Phillip Lord
2016-06-03 17:00 ` Stefan Monnier
2016-06-03 22:18 ` Phillip Lord
2016-06-04 3:05 ` Stefan Monnier
2016-06-04 8:51 ` Phillip Lord
2016-06-04 16:49 ` Stefan Monnier
2016-06-04 17:17 ` Phillip Lord
2016-06-04 18:41 ` Stefan Monnier
2016-06-06 14:33 ` Phillip Lord
2016-06-06 15:02 ` Stefan Monnier
2016-06-06 15:36 ` Phillip Lord
2016-06-06 15:26 ` Eli Zaretskii
2016-06-06 15:38 ` Phillip Lord
2016-06-06 16:22 ` Eli Zaretskii
2016-06-07 11:20 ` Phillip Lord
2016-06-07 15:09 ` Eli Zaretskii
2016-06-03 2:58 ` Chong Yidong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wpm9q4z7.fsf@russet.org.uk \
--to=phillip.lord@russet.org.uk \
--cc=23632@debbugs.gnu.org \
--cc=cyd@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).