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 23:23:27 +0100 Message-ID: <87inw9yy74.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> <87k2gqrmbe.fsf@russet.org.uk> <87zipl7gru.fsf@metalevel.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1468448690 12628 80.91.229.3 (13 Jul 2016 22:24:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Jul 2016 22:24:50 +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 Thu Jul 14 00:24:38 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 1bNSa4-0007PM-Iz for geb-bug-gnu-emacs@m.gmane.org; Thu, 14 Jul 2016 00:24:36 +0200 Original-Received: from localhost ([::1]:50317 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNSa3-0004Or-KW for geb-bug-gnu-emacs@m.gmane.org; Wed, 13 Jul 2016 18:24:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46992) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNSZb-000410-1h for bug-gnu-emacs@gnu.org; Wed, 13 Jul 2016 18:24:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bNSZW-0000QO-2B for bug-gnu-emacs@gnu.org; Wed, 13 Jul 2016 18:24:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37929) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNSZV-0000QK-SF for bug-gnu-emacs@gnu.org; Wed, 13 Jul 2016 18:24:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bNSZV-0001Dw-L3 for bug-gnu-emacs@gnu.org; Wed, 13 Jul 2016 18:24: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 22:24: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.14684486194676 (code B ref 23906); Wed, 13 Jul 2016 22:24:01 +0000 Original-Received: (at 23906) by debbugs.gnu.org; 13 Jul 2016 22:23:39 +0000 Original-Received: from localhost ([127.0.0.1]:50266 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bNSZ8-0001DK-Tz for submit@debbugs.gnu.org; Wed, 13 Jul 2016 18:23:39 -0400 Original-Received: from cloud103.planethippo.com ([31.216.48.48]:53448) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bNSZ5-0001D5-4d for 23906@debbugs.gnu.org; Wed, 13 Jul 2016 18:23:37 -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=LXZjZPJ+ROXR1ND8OKC35r4aJC9ctXC+OvcHKZR48pc=; b=EiiLSk5C7sQXf0L+XniIUayv12 sub4RLMkDonsDl8waREcv1EsO3JSVj+HoJ577uiwqZRYkVTs46SSQjZoXiWB8HNrBcBro4JjzYNPH SkIWBSH666GcHzdmDMTbU07cqVsdHVQazeZcVHcFusx9/ZvzY1Cr/nMOTmjhAzpKDbqwswhhW5pIH T2Twr0NCD5VDRzdcTiQoK9G82cRyO01b3NqxEIc4mKt0N7mi4utJKBG8O1gviIbJj98OW/VuqOX2E 5CR0d1uVDPauT8FxaYcMdJXq9FmB3n3UBroIbqpyjtB82ornqaHqmtSUc0kZp0zs+3wUzjhOFzEOa k1q2t++g==; Original-Received: from cpc1-benw10-2-0-cust373.gate.cable.virginm.net ([77.98.219.118]:59756 helo=russet.org.uk) by cloud103.planethippo.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1bNSYy-002FbU-Li; Wed, 13 Jul 2016 23:23:28 +0100 In-Reply-To: <87zipl7gru.fsf@metalevel.at> (Markus Triska's message of "Wed, 13 Jul 2016 16:29:41 +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:121040 Archived-At: Markus Triska writes: > phillip.lord@russet.org.uk (Phillip Lord) writes: > >>> 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. > > The way I imagine it, Y does not get "longer and longer", but is simply > an integer that gets higher and higher when more output arrives. That > would be one way to merge subsequent insertions in the undo list. Sorry, I didn't put that well. My point was, simply, that if the prolog output is too long, you have to put an boundary sooner or later, or Emacs is going to complain. >> 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. > > Please let us consider the more general issue of making *all* > insertions, the first _and also subsequent ones_ that happen during the > interaction with the Prolog process (and which can stem either from > process output *or* from user input) *atomic* in the sense that they are > all undone as a single unit. Please try out ediprolog to see what I > mean. In my view, the transaction concept that Stefan has proposed is a > very good solution for this and would benefit also other parts of Emacs. > It is this general issue that I would like to address and solve with a > suitable (likely: new) Emacs mechanism, not only the first %@. Already replied to this, in my other response. It's easy to add. > This seems completely normal and correct to me. Undo boundaries are > currently inserted without my control over them. I understand that this > is for efficiency reasons, to allow Emacs to trim the undo list. Just to be clear; it's not for reasons of efficiency. Emacs has to trim the undo list or Emacs has a memory leak. It currently has heuristic checks in place, which make Emacs produce a user visible error when it forcibly discards undo information. > I would like to have more control over this, for example, by removing > these undo boundaries when the whole interaction is over. At that > point, we know that Emacs has not raised an error, so it should be > very safe. That's true, but only for a defined set of prolog output. Still, I guess, hitting the undo limits is not a problem for ediprolog in general use, or you would have hit it already (as I say, it's pretty obvious when you do hit it!) > Several other solutions would also fit this particular case, such as > merging subsequent insertions in the undo list to keep its length > constant. These solutions should not depend on the timing of > insertions. > > We have found one case where I could prevent the undo boundary with > special-case code (for the initial %@), but a more general solution > would be much more welcome and work for all parts of the interaction. No worries, I'll add to master. Phil