all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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


  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

* 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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.