From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#23906: 25.0.95; Undo boundary after process output is not consistent Date: Tue, 12 Jul 2016 16:22:52 -0400 Message-ID: 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 1468355671 30741 80.91.229.3 (12 Jul 2016 20:34:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 Jul 2016 20:34:31 +0000 (UTC) Cc: Phillip Lord , 23906@debbugs.gnu.org To: Markus Triska Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jul 12 22:34:21 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 1bN4No-0005dP-Ez for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Jul 2016 22:34:20 +0200 Original-Received: from localhost ([::1]:43307 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bN4Nn-0006hS-Ms for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Jul 2016 16:34:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44067) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bN4Cv-0002q1-JJ for bug-gnu-emacs@gnu.org; Tue, 12 Jul 2016 16:23:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bN4Cs-0000sx-UY for bug-gnu-emacs@gnu.org; Tue, 12 Jul 2016 16:23:04 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36435) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bN4Cs-0000st-OL for bug-gnu-emacs@gnu.org; Tue, 12 Jul 2016 16:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bN4Cs-0007SL-HJ for bug-gnu-emacs@gnu.org; Tue, 12 Jul 2016 16:23:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Jul 2016 20:23: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.146835498128647 (code B ref 23906); Tue, 12 Jul 2016 20:23:02 +0000 Original-Received: (at 23906) by debbugs.gnu.org; 12 Jul 2016 20:23:01 +0000 Original-Received: from localhost ([127.0.0.1]:48772 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bN4Cr-0007Ro-8c for submit@debbugs.gnu.org; Tue, 12 Jul 2016 16:23:01 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:58619) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bN4Co-0007Ra-NP for 23906@debbugs.gnu.org; Tue, 12 Jul 2016 16:22:59 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A6FgA731xV/3mcpUVcgxCEAoVVwD6CTQQCAoE8PBEBAQEBAQEBgQpBBYNdAQEDAVYjBQsLNBIUGA0kiDcIzyMBAQEBAQEEAQEBAR6LOoUFB4QtBZ8Xg2uOKYIUgUUjgWYkHIFuIoJ4AQEB X-IPAS-Result: A0A6FgA731xV/3mcpUVcgxCEAoVVwD6CTQQCAoE8PBEBAQEBAQEBgQpBBYNdAQEDAVYjBQsLNBIUGA0kiDcIzyMBAQEBAQEEAQEBAR6LOoUFB4QtBZ8Xg2uOKYIUgUUjgWYkHIFuIoJ4AQEB X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="247625637" Original-Received: from 69-165-156-121.dsl.teksavvy.com (HELO pastel.home) ([69.165.156.121]) by ironport2-out.teksavvy.com with ESMTP; 12 Jul 2016 16:22:52 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id AD37F64405; Tue, 12 Jul 2016 16:22:52 -0400 (EDT) In-Reply-To: <874m7usn1m.fsf@metalevel.at> (Markus Triska's message of "Tue, 12 Jul 2016 20:56:21 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) 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:120956 Archived-At: > 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). > 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? 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. So I'm wondering to what extent your unsatisfaction is specific to ediprolog's interaction or whether it's more a matter of user preference. IOW, maybe we should we aim to provide that behavior not just in ediprolog.el but also in comint, based on some user config. > 3- Have Ediprolog use the same trick used in Viper where we wipe out > intermediate boundaries after the fact. > This sounds like a great option. Could you please tell me a bit more? In Viper, when you do an insertion (e.g. via the "i" key) here's what happens: while performing the insertion, the undo list is handled normally, with boundaries inserted automatically so that you can undo parts of what you're in the process of inserting; but when you finally exit with ESC Viper goes back through the buffer-undo-list and throws away all the boundaries that were added during the insertion, so that an undo gets rid of the whole insertion (i.e. all the steps that made up the insertion end up amalgamated into a single undo step). > The specific use case for me is: I have a process filter that > continuously (upon process output or user input) inserts text into the > buffer. I just want *all* this text gone when pressing C-/. If possible, > I hope that this can be done without the undo list growing too long. 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. If the "undo parts of the current response" behavior doesn't suit you, you could try to be more aggressive about getting rid of undo boundaries and (for example) remove them whenever new data is received from the process. > 4- Add the kind of "do it manually" option you had added earlier, such > that Ediprolog could request that Emacs refrain from auto-adding any > undo-boundaries in its buffer. > > To me, this sounds at least as great as (3) and maybe could be used by > both Viper and ediprolog if it were available? That's what we first used for Viper, but it turned out undesirable, because it prevents the user from undoing fine grained steps of the current insertion. > Ideally, only the output that stems from the interaction with the > Prolog process and user input during the interaction should be treated > as a single unit. This separation (i.e., treat insertions as a unit in > some parts of a buffer while applying the normal undo behaviour in other > parts) may of course be very hard to achieve, and I would already be > very satisfied if there is a way to make it work in the regular case. I > only mention for completeness that conceptually, I regard the text that > stems from the Prolog interaction different from editing operations. Getting it "right" in all cases may indeed be difficult (if for no other reason than because it's difficult to formally define what we mean by "right" in the general case). Stefan