From: Markus Triska <triska@metalevel.at>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Phillip Lord <phillip.lord@russet.org.uk>, 23906@debbugs.gnu.org
Subject: bug#23906: 25.0.95; Undo boundary after process output is not consistent
Date: Wed, 13 Jul 2016 00:35:42 +0200 [thread overview]
Message-ID: <874m7uqybl.fsf@metalevel.at> (raw)
In-Reply-To: <jwvshve1s2n.fsf-monnier+emacsbugs@gnu.org> (Stefan Monnier's message of "Tue, 12 Jul 2016 17:20:47 -0400")
Stefan Monnier <monnier@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
next prev parent reply other threads:[~2016-07-12 22:35 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-06 17:56 bug#23906: 25.0.95; Undo boundary after process output is not consistent Markus Triska
2016-07-06 18:38 ` Eli Zaretskii
2016-07-11 11:45 ` Phillip Lord
2016-07-11 13:54 ` Markus Triska
2016-07-12 16:29 ` Phillip Lord
2016-07-12 17:03 ` Stefan Monnier
2016-07-12 18:56 ` Markus Triska
2016-07-12 20:22 ` Stefan Monnier
2016-07-12 21:02 ` Markus Triska
2016-07-12 21:20 ` Stefan Monnier
2016-07-12 22:35 ` Markus Triska [this message]
2016-07-12 22:51 ` Stefan Monnier
2016-07-12 22:45 ` Markus Triska
2016-07-13 22:12 ` Phillip Lord
2016-07-14 8:34 ` Markus Triska
2016-07-14 13:33 ` Phillip Lord
2016-07-14 15:10 ` Markus Triska
2016-07-14 20:25 ` Phillip Lord
2016-07-14 22:12 ` Stefan Monnier
2016-07-18 4:18 ` Stefan Monnier
2016-07-18 19:03 ` Markus Triska
2016-07-19 0:41 ` Stefan Monnier
2016-07-19 1:05 ` Stefan Monnier
2016-07-24 15:45 ` Phillip Lord
2016-07-24 21:36 ` Stefan Monnier
2020-09-04 13:55 ` Lars Ingebrigtsen
2016-07-13 8:09 ` Phillip Lord
2016-07-13 14:29 ` Markus Triska
2016-07-13 22:23 ` Phillip Lord
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=874m7uqybl.fsf@metalevel.at \
--to=triska@metalevel.at \
--cc=23906@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=phillip.lord@russet.org.uk \
/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).