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: Thu, 14 Jul 2016 21:25:06 +0100 Message-ID: <87zipk3r31.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> <8760sao9im.fsf@metalevel.at> <87mvllyypo.fsf@russet.org.uk> <87zipkzkge.fsf@metalevel.at> <87shvcfiox.fsf@russet.org.uk> <87shvccl2h.fsf@metalevel.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1468528782 26345 80.91.229.3 (14 Jul 2016 20:39:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Jul 2016 20:39:42 +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 22:39:30 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 1bNnPq-0005rP-VE for geb-bug-gnu-emacs@m.gmane.org; Thu, 14 Jul 2016 22:39:27 +0200 Original-Received: from localhost ([::1]:56849 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNnPq-0007TO-8a for geb-bug-gnu-emacs@m.gmane.org; Thu, 14 Jul 2016 16:39:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48960) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNnCw-0006xV-L9 for bug-gnu-emacs@gnu.org; Thu, 14 Jul 2016 16:26:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bNnCs-0002Ux-CP for bug-gnu-emacs@gnu.org; Thu, 14 Jul 2016 16:26:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:39474) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNnCs-0002Ut-9j for bug-gnu-emacs@gnu.org; Thu, 14 Jul 2016 16:26:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bNnCr-0005m6-Vy for bug-gnu-emacs@gnu.org; Thu, 14 Jul 2016 16:26:02 -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: Thu, 14 Jul 2016 20:26: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.146852791622147 (code B ref 23906); Thu, 14 Jul 2016 20:26:01 +0000 Original-Received: (at 23906) by debbugs.gnu.org; 14 Jul 2016 20:25:16 +0000 Original-Received: from localhost ([127.0.0.1]:51811 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bNnC8-0005l7-7g for submit@debbugs.gnu.org; Thu, 14 Jul 2016 16:25:16 -0400 Original-Received: from cloud103.planethippo.com ([31.216.48.48]:42881) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bNnC5-0005kp-Uh for 23906@debbugs.gnu.org; Thu, 14 Jul 2016 16:25:14 -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=w0jfRJg1SmrNUVtPTcFS/QbpoT9Xs4SDWcJ4OPJpdFU=; b=yjgAqXxyb3sG2LtWFjPNzIPqvV Ph3wz7D61wijclpIPH3polcWACfES6C8YLSxX3Yy8mnh//HqgeCCN0b/xdbFhItNyPl6YBT38wp0W w50uy8lsbIhM4SQMpJ6cZFVp0HUmVizyPxyfNdOIZ5OC2HoMvyTyYe51IufoLrYapmn2/Z9XO28Vc ZV7CsbMWxrqH6iyxP+kRNEFxrgIFo3GP4yaMzG7LG4eBTFJMVR6QGvCfuQ5hS6hvxFUL2gK8201ux HH71GilV0mnl4fSHP1DjV/fSM3qWoUKUbiynMBk+1+ehgw2J4pzQsQInriti6GRLedPqziL94LTiw HCAFkxPA==; Original-Received: from cpc1-benw10-2-0-cust373.gate.cable.virginm.net ([77.98.219.118]:33413 helo=russet.org.uk) by cloud103.planethippo.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1bNnBz-001JT3-KS; Thu, 14 Jul 2016 21:25:07 +0100 In-Reply-To: <87shvccl2h.fsf@metalevel.at> (Markus Triska's message of "Thu, 14 Jul 2016 17:10:14 +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:121098 Archived-At: Markus Triska writes: > phillip.lord@russet.org.uk (Phillip Lord) writes: > >> It is sufficient though, to restore the old behaviour and fix the >> regression you have, which is the point of this bug! > >> We can think about doing something better (and which would work for >> viper also -- as Stefan says, the current solution has some issues). But >> I am not sure what this would look like at the moment. > > Please let us use this opportunity to fix the more general case > too. Stefan agreed that the following primitives would work: > > -) undo-begin-transaction > Starts a new transaction. > -) undo-end-transaction > Ends the most recently started undo transaction. > > The effects of all commands between would be undone as a single unit. Yep, but Stefan did say how to implement this! We could do the same thing as viper, which works, but has the issues he pointed out. Off hand, I do not see an easy solution. It's also worth saying that that viper has two very well defined modes -- insert and command -- which are core to its functionality. It begins the transaction when it enters insert mode, then ends the transaction when it leaves. I'm not seeing this with ediprolog. How are you going to be sure that each "begin" is paired with an "end"? > Introducing new variables that only change how the process timer works > would be made completely obsolete by such a solution: It would simply > fall out as one special case of such transactions, benefit ediprolog and > (very likely) Viper, and also other programs. Personally, I would have > no use case for only changing the process timer if such transactions > were available, since this is only one special case for me, even though > it is the one that is described in the very first post of this report. My solution is simple and easy and fits within a let binding. The solution you are looking for solves the much more complex case where you want undo to behave one way up to a point in time, and then amalgamate several undos post hoc. > I hope this approach or an equivalent one is possible in Emacs, and I > would be very grateful if you could look into this. At the moment, I am interested in fixing the regressions that I've caused by my changes to the undo system which I've nearly done -- you have a workaround at least, and I'll put something easier onto master. New undo functionality is not high on my list at the moment, am afraid. Happy to provide feedback if you want to add this for yourself, though. Phil