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 16:29:41 +0200 Message-ID: <87zipl7gru.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> <87k2gqrmbe.fsf@russet.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1468420230 16336 80.91.229.3 (13 Jul 2016 14:30:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Jul 2016 14:30:30 +0000 (UTC) Cc: Stefan Monnier , 23906@debbugs.gnu.org To: phillip.lord@russet.org.uk (Phillip Lord) Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jul 13 16:30:22 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 1bNLB7-0001eO-J7 for geb-bug-gnu-emacs@m.gmane.org; Wed, 13 Jul 2016 16:30:21 +0200 Original-Received: from localhost ([::1]:48056 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNLB6-0002Yu-Ra for geb-bug-gnu-emacs@m.gmane.org; Wed, 13 Jul 2016 10:30:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNLAt-0002Lx-GC for bug-gnu-emacs@gnu.org; Wed, 13 Jul 2016 10:30:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bNLAo-0002Xi-Ac for bug-gnu-emacs@gnu.org; Wed, 13 Jul 2016 10:30:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37587) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNLAo-0002Xe-70 for bug-gnu-emacs@gnu.org; Wed, 13 Jul 2016 10:30:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bNLAn-00034I-Vq for bug-gnu-emacs@gnu.org; Wed, 13 Jul 2016 10:30:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Markus Triska Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Jul 2016 14:30:01 +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.146842019411760 (code B ref 23906); Wed, 13 Jul 2016 14:30:01 +0000 Original-Received: (at 23906) by debbugs.gnu.org; 13 Jul 2016 14:29:54 +0000 Original-Received: from localhost ([127.0.0.1]:49924 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bNLAb-00033Y-N3 for submit@debbugs.gnu.org; Wed, 13 Jul 2016 10:29:54 -0400 Original-Received: from metalevel.at ([78.46.218.83]:36822) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bNLAV-00033I-P3 for 23906@debbugs.gnu.org; Wed, 13 Jul 2016 10:29:48 -0400 Original-Received: by metalevel.at (Postfix, from userid 1000) id 663ADA0077; Wed, 13 Jul 2016 16:29:41 +0200 (CEST) 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:120993 Archived-At: phillip.lord@russet.org.uk (Phillip Lord) writes: >> about it, but what I think would work in this particular case is to >> record it as "Emacs, to undo this, you need to remove all text between X >> and Y", and Y simply increases as more text is inserted into the buffer. >> This would keep the length of the undo list constant throughout the >> whole interaction with the subprocess, at least in this concrete >> case. Can I do this in ediprolog myself? If so, then I will do it. > > > And what happens if the prolog process spams and never stops? Y, gets > longer and longer. Eventually, Emacs signals an error with a "this is > probably a bug" message. The way I imagine it, Y does not get "longer and longer", but is simply an integer that gets higher and higher when more output arrives. That would be one way to merge subsequent insertions in the undo list. > I think you are doing two things -- one is telling the user that > something has happened and one is storing the result. I think that this > is the problem. > > My suggestion is add the %@ into the buffer when the result comes > through. If you want %@ to *appear* before this, then insert an overlay > with a display string. Please let us consider the more general issue of making *all* insertions, the first _and also subsequent ones_ that happen during the interaction with the Prolog process (and which can stem either from process output *or* from user input) *atomic* in the sense that they are all undone as a single unit. Please try out ediprolog to see what I mean. In my view, the transaction concept that Stefan has proposed is a very good solution for this and would benefit also other parts of Emacs. It is this general issue that I would like to address and solve with a suitable (likely: new) Emacs mechanism, not only the first %@. >> In the typical interaction mode, point cannot move between 1) and 4): >> Each key press is sent to the Prolog process, so that you can interact >> with Prolog like in a terminal. > > Emacs blocks? It is an interaction loop that can be left with C-g at any time. Please try out ediprolog to see what I mean, for example on the query: ?- length(Ls, L). > My own feeling here is, still, that while ediprolog's current system is > straight-forward, it's probably not correct! Please let me clearify: All that ediprolog does is inserting text into the buffer. The text can either stem from process output, user input, or (only in the very special case of the *first* %@ that is inserted when a new interaction starts) even by ediprolog directly, as hardcoded string. This seems completely normal and correct to me. Undo boundaries are currently inserted without my control over them. I understand that this is for efficiency reasons, to allow Emacs to trim the undo list. I would like to have more control over this, for example, by removing these undo boundaries when the whole interaction is over. At that point, we know that Emacs has not raised an error, so it should be very safe. Several other solutions would also fit this particular case, such as merging subsequent insertions in the undo list to keep its length constant. These solutions should not depend on the timing of insertions. We have found one case where I could prevent the undo boundary with special-case code (for the initial %@), but a more general solution would be much more welcome and work for all parts of the interaction. All the best, Markus