From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Markus Triska Newsgroups: gmane.emacs.bugs Subject: bug#23906: 25.0.95; Undo boundary after process output is not consistent Date: Wed, 13 Jul 2016 00:35:42 +0200 Message-ID: <874m7uqybl.fsf@metalevel.at> References: <83r3b6lih2.fsf@gnu.org> <87h9bw5rfd.fsf@russet.org.uk> <87eg70i8k5.fsf@metalevel.at> <87d1mikef5.fsf@russet.org.uk> <874m7usn1m.fsf@metalevel.at> <8760sao9im.fsf@metalevel.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1468362989 17664 80.91.229.3 (12 Jul 2016 22:36:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 Jul 2016 22:36:29 +0000 (UTC) Cc: Phillip Lord , 23906@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jul 13 00:36:19 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bN6Hn-0001b2-LE for geb-bug-gnu-emacs@m.gmane.org; Wed, 13 Jul 2016 00:36:15 +0200 Original-Received: from localhost ([::1]:43895 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bN6Hm-0004NU-UJ for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Jul 2016 18:36:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53732) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bN6Hg-0004NB-Mp for bug-gnu-emacs@gnu.org; Tue, 12 Jul 2016 18:36:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bN6Ha-0005PR-SF for bug-gnu-emacs@gnu.org; Tue, 12 Jul 2016 18:36:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36529) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bN6Ha-0005PN-Oc for bug-gnu-emacs@gnu.org; Tue, 12 Jul 2016 18:36:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bN6Ha-0002KE-KP for bug-gnu-emacs@gnu.org; Tue, 12 Jul 2016 18:36:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Markus Triska Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Jul 2016 22:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23906 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23906-submit@debbugs.gnu.org id=B23906.14683629488901 (code B ref 23906); Tue, 12 Jul 2016 22:36:02 +0000 Original-Received: (at 23906) by debbugs.gnu.org; 12 Jul 2016 22:35:48 +0000 Original-Received: from localhost ([127.0.0.1]:48866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bN6HL-0002JV-NR for submit@debbugs.gnu.org; Tue, 12 Jul 2016 18:35:47 -0400 Original-Received: from metalevel.at ([78.46.218.83]:35438) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bN6HH-0002JF-Q7 for 23906@debbugs.gnu.org; Tue, 12 Jul 2016 18:35:47 -0400 Original-Received: by metalevel.at (Postfix, from userid 1000) id AF1BDA0640; Wed, 13 Jul 2016 00:35:42 +0200 (CEST) In-Reply-To: (Stefan Monnier's message of "Tue, 12 Jul 2016 17:20:47 -0400") User-Agent: Emacs/24.4 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:120967 Archived-At: Stefan Monnier 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