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 17:20:47 -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> <8760sao9im.fsf@metalevel.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1468358491 14942 80.91.229.3 (12 Jul 2016 21:21:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 Jul 2016 21:21: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 23:21: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 1bN57I-0000D7-24 for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Jul 2016 23:21:20 +0200 Original-Received: from localhost ([::1]:43626 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bN57H-0003ue-80 for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Jul 2016 17:21:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36777) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bN575-0003rV-Ql for bug-gnu-emacs@gnu.org; Tue, 12 Jul 2016 17:21:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bN56z-0007N1-T1 for bug-gnu-emacs@gnu.org; Tue, 12 Jul 2016 17:21:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36487) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bN56z-0007Mp-PG for bug-gnu-emacs@gnu.org; Tue, 12 Jul 2016 17:21:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bN56z-0000SH-Ko for bug-gnu-emacs@gnu.org; Tue, 12 Jul 2016 17:21:01 -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 21:21: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.14683584551729 (code B ref 23906); Tue, 12 Jul 2016 21:21:01 +0000 Original-Received: (at 23906) by debbugs.gnu.org; 12 Jul 2016 21:20:55 +0000 Original-Received: from localhost ([127.0.0.1]:48824 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bN56s-0000Rp-O6 for submit@debbugs.gnu.org; Tue, 12 Jul 2016 17:20:54 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:47227) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bN56r-0000Rc-81 for 23906@debbugs.gnu.org; Tue, 12 Jul 2016 17:20:53 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BCFgA731xV/3mcpUVcgxCEAoVVwD6CTQQCAoE8PRABAQEBAQEBgQpBBYNdAQEDAVYjBQsLNBIUGA0kiDcIzyMBAQEBAQEEAQEBAR6LOoUFB4QtBZ8Xg2uQPYFFI4FmJByBbiKCeAEBAQ X-IPAS-Result: A0BCFgA731xV/3mcpUVcgxCEAoVVwD6CTQQCAoE8PRABAQEBAQEBgQpBBYNdAQEDAVYjBQsLNBIUGA0kiDcIzyMBAQEBAQEEAQEBAR6LOoUFB4QtBZ8Xg2uQPYFFI4FmJByBbiKCeAEBAQ X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="247637687" 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 17:20:47 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 46EAE64405; Tue, 12 Jul 2016 17:20:47 -0400 (EDT) In-Reply-To: <8760sao9im.fsf@metalevel.at> (Markus Triska's message of "Tue, 12 Jul 2016 23:02:09 +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:120962 Archived-At: > 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. Yes, but the real "%@" will only be inserted into the buffer when actual process output comes along (which you already do anyway, IIUC). > 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. That's right. > 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?): Please note in this case that, as explained above, the output normally is inserted continuously in a loop, but it is possible to break out of the loop with C-g and edit text elsewhere in the buffer, and in that case I still would like the normal undo behaviour for user input. Tho I guess you might be able to distinguish the two cases based on the C-g. Hmm... probably doable, but sounds delicate. > 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. So it's not absolutely indispensable, but it's indeed more annoying than in the "usual" comint case because undo is used more often and even repeatedly, so predictability is more important than usual. I see, makes sense. >> 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. 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). Maybe we should add some support in some "core" file (subr.el or something) for that operation. Stefan