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#22295: viper-mode undo bug introduced between Nov 10 and Nov 14 Date: Fri, 10 Jun 2016 23:18:29 +0100 Message-ID: <8760tghemi.fsf@russet.org.uk> References: <83vb2h6lfq.fsf@gnu.org> <83r3d56jrg.fsf@gnu.org> <87poso7nf5.fsf@russet.org.uk> <878tzatbte.fsf@russet.org.uk> <877fe85z1e.fsf@russet.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1465597168 32086 80.91.229.3 (10 Jun 2016 22:19:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Jun 2016 22:19:28 +0000 (UTC) Cc: 22295@debbugs.gnu.org, Jim Meyering , Michael Kifer To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jun 11 00:19:16 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 1bBUln-0003py-Nd for geb-bug-gnu-emacs@m.gmane.org; Sat, 11 Jun 2016 00:19:15 +0200 Original-Received: from localhost ([::1]:44703 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBUlm-0006zR-Ss for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Jun 2016 18:19:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33257) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBUlg-0006z2-NH for bug-gnu-emacs@gnu.org; Fri, 10 Jun 2016 18:19:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bBUla-00067X-IQ for bug-gnu-emacs@gnu.org; Fri, 10 Jun 2016 18:19:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52204) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBUla-000679-Bf for bug-gnu-emacs@gnu.org; Fri, 10 Jun 2016 18:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bBUla-00033T-0b for bug-gnu-emacs@gnu.org; Fri, 10 Jun 2016 18:19: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: Fri, 10 Jun 2016 22:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22295 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22295-submit@debbugs.gnu.org id=B22295.146559711911715 (code B ref 22295); Fri, 10 Jun 2016 22:19:01 +0000 Original-Received: (at 22295) by debbugs.gnu.org; 10 Jun 2016 22:18:39 +0000 Original-Received: from localhost ([127.0.0.1]:36308 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bBUlD-00032s-CV for submit@debbugs.gnu.org; Fri, 10 Jun 2016 18:18:39 -0400 Original-Received: from cloud103.planethippo.com ([31.216.48.48]:48508) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bBUlB-00032f-BN for 22295@debbugs.gnu.org; Fri, 10 Jun 2016 18:18: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=TKLrIP7GS7jbjafPpi/cQ+Nd83lNjRlhSvW2h1nNxJw=; b=wDobiGN5o7X/9V2MbEzsyqqKkv gP3y8FSrjl13zFU/hGmhUkAkC01F/Ob2RDa082NLmitniN9FnabaPLptpEet0wtCQrG11mqiD4+Pp +DDUX9iRfL3RMnhAZVS9X7O/THv53654xeIwk6aK3RLi6UPF1c1AnnZV2cO2FgrJCQp8RvAv4VhSi KVxTLowQvMvuDCCBD9H6y+J8uiwfIaDAd8EvP93U/PRVOgVsL+yw59+mafliTEyQUY4TkF687+Wvt kzmWMnsCHm8yfGev9h+Sqm2u1dhLh6Yvu35+4q9kCGWdpDZakjt0HXiOiDgWstGi6zOqJsEBAUkw+ EriEV8rg==; Original-Received: from cpc1-benw10-2-0-cust373.gate.cable.virginm.net ([77.98.219.118]:48854 helo=russet.org.uk) by cloud103.planethippo.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1bBUl4-000r9X-AQ; Fri, 10 Jun 2016 23:18:30 +0100 In-Reply-To: (Stefan Monnier's message of "Fri, 10 Jun 2016 13:05:22 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.94 (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:119400 Archived-At: Stefan Monnier writes: >>> The old code seemed "simple" enough that the problem was probably >>> simple to fix (once identified). >> Well, most problems are simple to fix once you actually know what they >> are. > > The problem seems to be the following: when you hit ESC, Viper will remove > boundaries from the undo-list, without making any changes to the buffer, > so the top-level loop won't add a boundary before the next command and > ends up hence "amalgamating" the next command with the previous one. > > In the old code, we just always blindly added a boundary to > current-buffer before running a command, whereas now we only do so if > the buffer has been modified since the last time we pushed a boundary. > > I think the patch below fixes the original problem. > Another way to fix it would be to change undo-auto--add-boundary so it > always considers (current-buffer) regardless of > undo-auto--undoably-changed-buffers. Stefan Many thanks for working this out -- I was going crazy trying to track this down, and I was looking in the wrong place all along. I've tried your patch against emacs-25 (after reverting c0139e32f1f3b) and it appears to work. The current behaviour of undo-auto--add-boundary seems sensible to me; the difference in behaviour only shows up because viper is manipulating the undo-list. I can try modifying u-a--a-b though -- viper is, I am sure, not the only package to fiddle with undo. I'd propose adding this to emacs-25. Eli, are you happy with this --- my last fix appears to not work and Stefans approach is much more discrete. As a separate issue, I'd like to add part of c0139e32f1f3b back though to master -- adding the variable undo-auto-disable-boundaries. It's not immediately necessary now, but it seems a useful option to have. Phil