From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@russet.org.uk (Phillip Lord) Newsgroups: gmane.emacs.bugs Subject: bug#23906: 25.0.95; Undo boundary after process output is not consistent Date: Wed, 13 Jul 2016 09:09:41 +0100 Message-ID: <87k2gqrmbe.fsf@russet.org.uk> 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 1468397427 9218 80.91.229.3 (13 Jul 2016 08:10:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Jul 2016 08:10:27 +0000 (UTC) Cc: Stefan Monnier , 23906@debbugs.gnu.org To: Markus Triska Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jul 13 10:10: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 1bNFFF-0003Dd-Fr for geb-bug-gnu-emacs@m.gmane.org; Wed, 13 Jul 2016 10:10:13 +0200 Original-Received: from localhost ([::1]:45783 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNFFE-0008AE-Iu for geb-bug-gnu-emacs@m.gmane.org; Wed, 13 Jul 2016 04:10:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44496) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNFF7-00088i-Fb for bug-gnu-emacs@gnu.org; Wed, 13 Jul 2016 04:10:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bNFF4-0000oZ-6J for bug-gnu-emacs@gnu.org; Wed, 13 Jul 2016 04:10:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36685) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNFF4-0000oU-23 for bug-gnu-emacs@gnu.org; Wed, 13 Jul 2016 04:10:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bNFF3-0000k0-PP for bug-gnu-emacs@gnu.org; Wed, 13 Jul 2016 04:10:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: phillip.lord@russet.org.uk (Phillip Lord) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Jul 2016 08:10: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.14683973912826 (code B ref 23906); Wed, 13 Jul 2016 08:10:01 +0000 Original-Received: (at 23906) by debbugs.gnu.org; 13 Jul 2016 08:09:51 +0000 Original-Received: from localhost ([127.0.0.1]:49022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bNFEt-0000jV-9g for submit@debbugs.gnu.org; Wed, 13 Jul 2016 04:09:51 -0400 Original-Received: from cloud103.planethippo.com ([31.216.48.48]:40294) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bNFEr-0000jI-6a for 23906@debbugs.gnu.org; Wed, 13 Jul 2016 04:09:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=russet.org.uk; s=default; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From; bh=+dBagVBClaE1MJU+DdYrOoeeEZVR6qCDG6D1XzKXcXY=; b=SGY4rQicNMmr4xNmH4zR48jqSV yxzrjmYLAEpBw7Ye9ng6qUgxNLR21x6lnpLxMilPdH00sykEtsPAhMjZqpkDE8AVlk9ld0FPrlgOJ ebjddV8hZ4UMtNBRPM5ejQmzPIgqyFK3oWuILvFN3arAl/nz5F3wa3wIrF5L66idb+slDt+HdAMUE ZNU0VyoX3kXibLnao39p1OUa2VJIEMxC8YKKmpjg53XC8ddjBMI8S+4KBh8MSLuK14aAstuMn+pHX 3dlCSR4FhPfSDRTUltcL+Hkv8gUIrgqP+YXRBTBZjaRFiSQbq59/TdVc+ScSpDD0VBy2Ehvromor6 C1cSW1/A==; Original-Received: from cpc1-benw10-2-0-cust373.gate.cable.virginm.net ([77.98.219.118]:58030 helo=russet.org.uk) by cloud103.planethippo.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1bNFEk-00018o-Hu; Wed, 13 Jul 2016 09:09:42 +0100 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.0.95 (gnu/linux) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud103.planethippo.com X-AntiAbuse: Original Domain - debbugs.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - russet.org.uk X-Get-Message-Sender-Via: cloud103.planethippo.com: authenticated_id: phillip.lord@russet.org.uk X-Authenticated-Sender: cloud103.planethippo.com: phillip.lord@russet.org.uk 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:120981 Archived-At: Markus Triska writes: > Yes, this is the core issue. In simulans2.sh which I posted, you can try > different time spans between 1) and 4) easily by modifying line 15. For > example, if I change 1.5 to 10, I always get an undo boundary after the > initial %@. If I change it to 4 or 5, I still only sometimes get one. My > estimate is thus that the timer runs about once every 10 seconds ;-) Yep, every 10 seconds. > > >>> 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. >> >> The problem here also is what happens if the process output is long. >> Emacs will now add undo-boundaries periodically. Before, I think, the >> undo list would have got longer and longer, until emacs errored. > > To clearify, the use case of ediprolog indeed comprises a single flow of > insertions, either stemming from process output or user input, while the > Prolog query is in process: Everything the Prolog process outputs is > inserted. Everything the user inputs is also inserted into the buffer > (and sent to the process). The result is a complete transcript of the > Prolog interaction just as it would normally happen on the terminal. > > For this particular case, I would be perfectly OK if undo would simply > undo the whole flow of insertions up to the point where the query was > started. I do not know much about the undo representation or your plans > 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. >> Yes. Or rather you could insert %@ immediately before getting data back >> from prolog, perhaps with a process filter. Then both of your insertions >> would be happening together. > > I am already using a process filter: If the process outputs \n, then I > insert \n%@ into the buffer. Only for the very first %@ that I insert > directly after the query is started, I am currently doing it outside the > process filter. It is important to insert %@ immediately to give an > indication that the query has been sent to the process (which may take a > long time to produce output). Note that % starts a Prolog line comment, > so the process output that gets embedded in buffers does not interfere > 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 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. >> Also, what happens if point moves between 1) and 4)? > > 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? > 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? > 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. I don't think that this is needed here. Viper has this because it removes undo-boundaries when it changes modes -- so it needs to add undo-boundaries which it later takes out. > 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? I have no particular problem with adding this (although not for Emacs 25.1 now!). Again, the caveat is, if the process is long or continual you MUST do something to call undo-boundary periodically, or Emacs will error. > > 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. Yeah, that's straight-forward -- add undo-boundary on non local exit. My own feeling here is, still, that while ediprolog's current system is straight-forward, it's probably not correct! Phil