GNU bug report logs - #23906
25.0.95; Undo boundary after process output is not consistent

Previous Next

Full log

Message #35 received at 23906 <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 23906 <at> debbugs.gnu.org,
 Phillip Lord <phillip.lord <at> russet.org.uk>
Subject: Re: bug#23906: 25.0.95;
 Undo boundary after process output is not consistent
Date: Wed, 13 Jul 2016 00:35:42 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> This is certainly doable, but not sufficient. An interaction with the
>> Prolog process can span several answers and even involve user input, and
>> I want all this to be removed again on undo. Please see below for more.
>
> Hmm... So are you saying that you want a single undo step to undo
> something that corresponds to "some process output plus some user
> input"?  This seems incompatible with the desire you expressed earlier
> to insert undo-boundaries whenever the user actually inserts
> something in the buffer (or did I misunderstand it?):

The interaction with Prolog (after the query is sent) consists of:

   a) output of the Prolog process
   b) user input to the Prolog process ("next answer", "exit" etc.)

*Both* lead to insertion of text in the buffer, and in this sense should
be treated completely alike: It all happens in the context of
"interaction with the Prolog process". When this interaction is over
(typically, no more answers or user pressed ".") and undo is desired,
*everything* that happened during this interaction should be undone at
once. The issue I reported was always that *too many* undo boundaries
were inserted in some cases, never too few. I want fewer boundaries, so
that I can always undo the entire interaction (output + input) at once.

> In case you haven't found it yet, "grep undo-boundary
> lisp/emulation/viper*.el" gets you straight to the relevant code (in
> emacs-25 or more recent).

Thank you, I have been looking at it already.

As far as I understand the code, this keeps track, via a special element
that normally does not occur in the undo list, of where the boundary
should be. Later, it removes all undo boundaries up to and including
that marker. I have a quite uneasy feeling about this: Can there be a
situation where the marker element unexpectedly remains in the undo
list? From a quick glance, maybe unwind-protect is what would be needed
in ediprolog to reliably remove such a marker also if C-g is pressed.

Other than that, I still do not understand why the timer is now
implemented in Emacs to insert undo boundaries during process output. I
have looked at the way the buffer-undo-list is stored, and it seems to
me that a continuous stream of process output that is inserted in the
buffer can be stored in the undo list quite efficiently, and that
inserting undo boundaries only further increases the length. So, how do
undo boundaries that are inserted by timers help to improve efficiency?

> Maybe we should add some support in some "core" file (subr.el or
> something) for that operation.

That would be awesome! Like "undo-begin-transaction", which could
prepare an atomic undo operation over many subsequent operations, and
"undo-end-transaction", which would remove all undo boundaries in it?

All the best!
Markus

Previous Next

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