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: Mon, 11 Jul 2016 15:54:50 +0200 Message-ID: <87eg70i8k5.fsf@metalevel.at> References: <83r3b6lih2.fsf@gnu.org> <87h9bw5rfd.fsf@russet.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1468245329 18699 80.91.229.3 (11 Jul 2016 13:55:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 Jul 2016 13:55:29 +0000 (UTC) Cc: 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 Mon Jul 11 15:55:20 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 1bMbg6-0004bD-Na for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Jul 2016 15:55:18 +0200 Original-Received: from localhost ([::1]:33823 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMbg2-0002HN-Mg for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Jul 2016 09:55:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50412) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMbfq-0002Cz-U0 for bug-gnu-emacs@gnu.org; Mon, 11 Jul 2016 09:55:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bMbfp-00066P-Tw for bug-gnu-emacs@gnu.org; Mon, 11 Jul 2016 09:55:02 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33820) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMbfp-00066I-Q0 for bug-gnu-emacs@gnu.org; Mon, 11 Jul 2016 09:55:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bMbfp-0002Ny-KN for bug-gnu-emacs@gnu.org; Mon, 11 Jul 2016 09:55:01 -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: Mon, 11 Jul 2016 13:55: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.14682452949148 (code B ref 23906); Mon, 11 Jul 2016 13:55:01 +0000 Original-Received: (at 23906) by debbugs.gnu.org; 11 Jul 2016 13:54:54 +0000 Original-Received: from localhost ([127.0.0.1]:46146 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bMbfh-0002NU-Rw for submit@debbugs.gnu.org; Mon, 11 Jul 2016 09:54:54 -0400 Original-Received: from metalevel.at ([78.46.218.83]:32937) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bMbff-0002NL-Ih for 23906@debbugs.gnu.org; Mon, 11 Jul 2016 09:54:51 -0400 Original-Received: by metalevel.at (Postfix, from userid 1000) id 34D61A0666; Mon, 11 Jul 2016 15:54:50 +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:120840 Archived-At: phillip.lord@russet.org.uk (Phillip Lord) writes: > I assume that the %@ is inserted first before the process is started, > then the results put in after the results come back? The precise sequence is (see `ediprolog-query' and `ediprolog-interact'): 1) "\n%@ " is inserted into the buffer 2) the Prolog process is started (if necessary) 3) the query is sent to the process 4) when process output arrives, it is appended to the buffer. The buffer is modified only by (1) and (4). Somtimes there is an undo boundary between them, and most often there is none (which I prefer). > This would mean that after the insertion of %@ there would be no > undo-boundary. That's exactly what I expect to happen. But in some cases, there unexpectedly *is* an undo boundary between two subsequent insertions of text into the buffer, namely between (1) and (4) above. > You could check by adding %@ immediately before you insert data from > prolog, rather than after you send data to it. To me, this makes more > sense -- you are adding text over an elongated period (i.e. during the > evaluation) without the expectation of an undo boundary. I will try this, thank you for the suggestion! For completeness: I now insert %@ *before* I send data to Prolog: (1), then (3) above. I suppose you means that I should do (1) immediately before (4), which in fact means that I then *would* insert %@ *after* sending data to Prolog. > Likewise, forcing an undo-boundary immediately after %@ would give you > consistent behaviour (although different). Yes, that would be consistent but rather the opposite of what I want: I would like to avoid the undo-boundary in all cases. > In this case, though, I am inclined toward suggesting changing > ediprolog.el. I am willing to do that if it achieves consistent results. However, a bit of reflection is in order because other packages may benefit at the same time by a more general solution. Please let me know if the use case is now clear: To repeat, the issue I am reporting is that sometimes there unexpectedly is an undo boundary although I do not want one. From the above, it seems that you agree that there should never be an undo boundary if the insertion of %@ is directly (except for timing) followed by the insertion of arriving process output. Yet, the timing seems to be critically involved. So, what would be a general way to always prevent an undo boundary between insertions that are separated only by time? I really like your suggestion to temporarily suppress the timer on a specific buffer, say via a let-binding, while the interaction is in progress. This would allow users to always undo the *whole* interaction with Prolog using a single undo. This is what is typically needed when using ediprolog: You interact with Prolog, and then undo the whole interaction. In this use case, undo boundaries only get in the way. I can make this configurable in ediprolog to perserve memory, if needed. Thank you and all the best! Markus