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: Tue, 12 Jul 2016 23:02:09 +0200 Message-ID: <8760sao9im.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1468357400 28332 80.91.229.3 (12 Jul 2016 21:03:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 Jul 2016 21:03:20 +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 Tue Jul 12 23:03:14 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 1bN4pl-00069b-QZ for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Jul 2016 23:03:14 +0200 Original-Received: from localhost ([::1]:43473 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bN4pl-0005ot-6h for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Jul 2016 17:03:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54562) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bN4pf-0005ah-55 for bug-gnu-emacs@gnu.org; Tue, 12 Jul 2016 17:03:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bN4pa-00017V-Uk for bug-gnu-emacs@gnu.org; Tue, 12 Jul 2016 17:03:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36464) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bN4pa-00017Q-Qs for bug-gnu-emacs@gnu.org; Tue, 12 Jul 2016 17:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bN4pa-0008SP-Fb for bug-gnu-emacs@gnu.org; Tue, 12 Jul 2016 17:03: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 21:03: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.146835733232450 (code B ref 23906); Tue, 12 Jul 2016 21:03:02 +0000 Original-Received: (at 23906) by debbugs.gnu.org; 12 Jul 2016 21:02:12 +0000 Original-Received: from localhost ([127.0.0.1]:48801 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bN4ol-0008RJ-P9 for submit@debbugs.gnu.org; Tue, 12 Jul 2016 17:02:12 -0400 Original-Received: from metalevel.at ([78.46.218.83]:35263) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bN4ok-0008RC-Pq for 23906@debbugs.gnu.org; Tue, 12 Jul 2016 17:02:11 -0400 Original-Received: by metalevel.at (Postfix, from userid 1000) id B6926A0640; Tue, 12 Jul 2016 23:02:09 +0200 (CEST) In-Reply-To: (Stefan Monnier's message of "Tue, 12 Jul 2016 16:22:52 -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:120959 Archived-At: Stefan Monnier writes: >> with the Prolog program itself. For this reason, text properties would >> not be a good fit for this use case: Users often want to store the query >> results together with the source code, and using %@ allows that. > > I think he meant to use text-properties (actually, I think it would > probably be an overlay) to *display* the special initial "%@" (which you > currently insert manually "to give an indication that the query has been > sent to the process") without actually inserting it in the buffer > (e.g. with an after-string or some such). Yes, I also understood it this way. Just to clearify: Eventually, there actually must be a %@ as real text in the buffer, because otherwise what the Prolog process emits will make the buffer no longer a valid Prolog program. So, what the Prolog process emits must not only *appear* as "commented out" in the buffer, but must actually *be* commented out. A text property may get us over the initial %@ until process output arrives, but at that point we will have to actually insert %@ into the buffer, so that the query result does not interfere with the program when users save it, or simply reconsult the buffer plus answer. 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. >> 1- just let the user hit undo an extra time when that happens. >> That is the current state that I consider a bit unsatisfying, so I would >> like to choose between 2, 3 and 4. > > Could you explain a bit why this is unsatisfying in ediprolog's case? One important reason for this is the way that ediprolog is frequently used: Typically, you use ediprolog to evaluate small self-contained test cases and important queries directly within your buffer. Almost always within a Prolog file, but of course also when composing e-mails to discuss important Prolog features, bug reports, answer questions etc. One very typical example: A user sends me a bug report together with sample code, sample query and its result. Using ediprolog, I can - directly from within the mail buffer - consult the code and evaluate the query, and quickly see whether I can reproduce the problem. I leave this evaluation in the buffer, can work on a fix in the library code, reconsult the program, re-run the query, and extremely easily compare the results because the previous result is also still in the buffer and in fact placed directly on the line below the current one. As such, I often use ediprolog to try out small self-contained test cases while I am still developing a feature or working on a fix, to track the current behaviour. At the same time, the test itself is often also under development, so I cannot yet solidify this as an automated unit test. Therefore, what it comes down to is often: *) work, work on fix *) peek, peek at result *) work, work on fix *) ... And for such smaller peeks at the current results, I frequently need to undo the whole interaction, and it is valuable during develpoment that undo is extremely consistent in what it does. It is irritating to always use C-/ for undo, except for 1 out of 10 times in such cases. > In my shell buffers, I sometimes use undo and am generally happier with > undo steps that are too fine grained than with undo steps which are too > coarse because it's easier to just repeat C-/ than to try and recreate > a missing intermediate point in the middle of an undo step. I understand this. In the case of ediprolog, the good news is that the whole interaction is *always* logged in a completely different buffer too: *ediprolog-history* shows precisely what was sent to the Prolog process, and what was emitted by the process, and users can always look at that buffer if there is any doubt in retrospect about what was done. Therefore, I would rather provide a consistent way for users to undo the whole interaction at once. It can always be lookep up later if needed. > IOW, maybe we should we aim to provide that behavior not just in > ediprolog.el but also in comint, based on some user config. Yes! Thank you for taking this general perspective. I must say at this point that I have no experience with how such a "transactional" undo would actually work out in practice. I can imagine that it is a bit unusual at first. For ediprolog though, I am quite certain that I would prefer it because, as explained above, the interactions are typically short, and breaking up a short interaction into two or more parts only 1 out of N times is definitely worse than always treating it as a unit. For comint and other modes, I can imagine that it could also be useful. > In Viper, when you do an insertion ... Thank you for the explanation! > Using Viper's approach, you could for example throw away the > undo-boundaries added since the last process-send-string. I'd expect > you'd do it right when you see Prolog's prompt. So if you undo while > Prolog is still in the middle of responding you might only undo parts of > the current response (like now), but once a response is complete it will > always be undone as an indivisible step. This sounds like a great approach, thank you! I will try this. All the best! Markus