GNU bug report logs - #23632
25.1.50; Gratuitous undo boundary in latex-insert-block

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: phillip.lord <at> russet.org.uk (Phillip Lord)
Cc: Chong Yidong <cyd <at> gnu.org>, 23632 <at> debbugs.gnu.org
Subject: bug#23632: 25.1.50; Gratuitous undo boundary in latex-insert-block
Date: Wed, 01 Jun 2016 09:15:37 -0400

> 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.

> 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.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.