From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Kifer Newsgroups: gmane.emacs.bugs Subject: bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14 Date: Sat, 14 May 2016 16:10:14 -0400 Message-ID: <57378626.8060205@cs.stonybrook.edu> References: <83vb2h6lfq.fsf@gnu.org> <83r3d56jrg.fsf@gnu.org> <87poso7nf5.fsf@russet.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1463256684 17630 80.91.229.3 (14 May 2016 20:11:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 May 2016 20:11:24 +0000 (UTC) Cc: 22295@debbugs.gnu.org, jim@meyering.net To: Phillip Lord , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat May 14 22:11:13 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 1b1fu3-0001Tv-8o for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 May 2016 22:11:11 +0200 Original-Received: from localhost ([::1]:38781 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b1fu2-0008KM-GY for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 May 2016 16:11:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39101) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b1fty-0008GX-Ce for bug-gnu-emacs@gnu.org; Sat, 14 May 2016 16:11:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b1ftu-0004Ey-3z for bug-gnu-emacs@gnu.org; Sat, 14 May 2016 16:11:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:39399) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b1ftu-0004Es-0P for bug-gnu-emacs@gnu.org; Sat, 14 May 2016 16:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1b1ftt-0006ap-QA for bug-gnu-emacs@gnu.org; Sat, 14 May 2016 16:11:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Kifer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 May 2016 20:11: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.146325662325297 (code B ref 22295); Sat, 14 May 2016 20:11:01 +0000 Original-Received: (at 22295) by debbugs.gnu.org; 14 May 2016 20:10:23 +0000 Original-Received: from localhost ([127.0.0.1]:51736 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b1ftH-0006Zx-Dc for submit@debbugs.gnu.org; Sat, 14 May 2016 16:10:23 -0400 Original-Received: from mail-qg0-f53.google.com ([209.85.192.53]:35918) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b1ftE-0006Zk-TW for 22295@debbugs.gnu.org; Sat, 14 May 2016 16:10:21 -0400 Original-Received: by mail-qg0-f53.google.com with SMTP id w36so73534074qge.3 for <22295@debbugs.gnu.org>; Sat, 14 May 2016 13:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs-stonybrook-edu.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=hR9R0iglkC3wjq+LAb9MDz8bog+ZeY9nQTsrjLACA+g=; b=SL10cWWgjnb1evRKOELYaM9UfpxaZCJ/0K0YTUXAOVAiewq/shD2IvYoSWYHBcTIWG gQDYdvzSwwG9s8Gfb9mIahwygPz9ZRjj/Fy4gOL+aCH2HxZCFfOLyCB8JzZTKEDBY4UL piQ8pSJwmnzecNbRdbeJMX/3PPMTfmW6WE1E0l2EwoRoGHFhIEK+m4JCVkYnP9hqz8zr I4cntHiEDaMWRgy6vgowQPOo8OzF+MaOoeXfnSAjCpuA88xNvxVmeAWwV8M+9gOfXr5t WWKFjZy5ZRziM3BA1oTdq1XAp35k5oB8touX1A4MK7j1950c82oNgVAFMGvZKf0VawIf Q+hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=hR9R0iglkC3wjq+LAb9MDz8bog+ZeY9nQTsrjLACA+g=; b=l5RgRqB0Z25R1RIX8EgmknMaolp6TS1lKFB71o4Gan2BFn6beovXpM8+Jj+SBdaaUk 7jFTlS/eO/grcWL3dYe6d1KfY+csPRQa8XH1RIEbf550I0zguun2YXS+gF84F3DktEJ5 lzhWAqsY3P3LOnR5lZ5ojzsvOKCuH2bB0GYl2o1IlWFu4qzo9WSUYlC8tU0xZQFpbAuC 7pwLwhta3ogjutW3+0AY/LN/XL1pfHZQz2Ce0Rphc2Hw3z0Ait4eeU5RI0QUzPkSuKhr Y5v6uUcmUO9Em0BwqI/D4UPrm4jX3pdJXuTuLNRzMd1t6GL2rzHZybyqWrCv9Sp0mV+z fLYQ== X-Gm-Message-State: AOPr4FWJSDfgELTqrCLMRqGo+6GZ4dswok0kQOc/grV/e2OdxWppMQxCNh0wekfYHpXvmKiv X-Received: by 10.140.97.180 with SMTP id m49mr6104507qge.102.1463256615506; Sat, 14 May 2016 13:10:15 -0700 (PDT) Original-Received: from [192.168.1.106] (ool-18ba1846.dyn.optonline.net. [24.186.24.70]) by smtp.gmail.com with ESMTPSA id x79sm11186655qka.37.2016.05.14.13.10.14 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 May 2016 13:10:15 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 In-Reply-To: <87poso7nf5.fsf@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:118243 Archived-At: On 05/14/2016 09:57 AM, Phillip Lord wrote: > Eli Zaretskii writes: > >>> Date: Sat, 14 May 2016 12:25:13 +0300 >>> From: Eli Zaretskii >>> Cc: 22295@debbugs.gnu.org, Jim Meyering >>> >>>> From: Jim Meyering >>>> Date: Sat, 2 Jan 2016 20:01:36 -0800 >>>> >>>> Hello, >>>> I noticed that viper-mode's "undo" ('u') command began to undo too much >>>> and was able quickly to determine that it worked fine with my snapshot >>>> built from git master some time on Nov 10, yet that it began to undo >>>> too much four days later. >>>> >>>> To demonstrate the problem (without risking changing anything in your >>>> home directory), run this: >>>> >>>> mkdir /tmp/x && HOME=/tmp/x emacs -Q -f viper-mode -nw >>>> ~/previously-nonexistent-file >>>> >>>> then respond "y", "y", "5" to get past the "viperize" setup questions. >>>> To reproduce the error, insert two lines, terminating each "insertion" with ESC, >>>> so that each is recorded as a separate undo'able operation. I.e., type this >>>> >>>> a 1 ESC >>>> >>>> to create the first line, then >>>> >>>> o 2 ESC >>>> >>>> to create the second. >>>> Finally, hit "u" to undo creation of the second and you'll see that it undoes >>>> both operations, erasing both lines. This is rather disruptive when that first >>>> bit of text was a long paragraph or two -- the novice may think that it's lost, >>>> because redo does not restore it -- however, it is available in emacs's >>>> yank buffer. >>> Phillip, could you please look into this? This sounds like a annoying >>> problem for users of viper-mode, and AFAIU it happens on the release >>> branch as well. >> (Adding Michael to the addressees.) >> >> I took a short look, and it sounds like we need more experts here. >> Undo in viper has its own implementation, which tries to do something >> that is not immediately clear to me, and is not really documented >> anywhere. I guess vi users will know that, but I'm not one of them. >> >> The viper-undo command and related functions manipulate the Emacs undo >> data structures directly, see viper-adjust-undo. I guess the recent >> changes in low-level undo implementation run afoul of what viper-mode >> tries to do. >> >> I hope the above provides enough hints to find the reason for this >> problem and solve it. >> > > Sorry for slow response -- was travelling. > > Yep, viper is doing strange things to undo -- it adds a symbol ('viper) > to the undo list, then removes it later, amalgamating everything upto > 'viper. I don't remember much myself, but the issue is this (and it is documented): In VI, the granularity of undoing is much coarser than in Emacs. Several ops that Emacs undoes in multiple steps are supposed to be undone with just one "undo" in VI. Viper simulates this by inserting viper-buffer-undo-list-mark onto buffer-undo-list to mark the point to which the Emacs undo's are to be run in order to accomplish one VI-style undo. In Emacs, as I vaguely remember, this role is played by nil(?), but VI-style undos are coarser than that, so viper requires its own marker on the unfo list. Hope this helps. Sorry that I don't have much time these days to work on viper. :-( -- --- michael > > I've got a complete test case (below in case anyone is interested -- > I'll make a proper unit test of it on master eventually). > > > On e0f64e7b4f9c3bbc12c4909ca8c8aa751f1fca4a (a random commit around > the time of the error). This produced a undo list like so: > > (nil > (2 . 4) > nil > (2 . 3) > (1 . 2) > (t . -1)) > > While on emacs-25 it gives (my comments): > > > ((3 . 4) ;; insertion from 3 to 4 > (2 . 3) ;; insertion from 2 to 3 > nil ;; boundary > (2 . 3) ;; insertion from 2 to 3 > (1 . 2) ;; insertion from 1 to 2 > (t . -1) ;; buffer created with file that does not exist > ) > > > So it looks like the amalgamation that Emacs is supposed to be doing is > failing. No idea at all where the head "nil" has gone. > > Will work on this more. > > > > (setq viper-inhibit-startup-message 't) > (setq viper-expert-level '5) > > (find-file "/tmp/file.txt") > (setq viper-mode t) > (require 'viper) > > ;; leave emacs lisp in Emacs mode or edebug becomes impossible > (setq viper-vi-state-mode-list (delq > 'emacs-lisp-mode > viper-vi-state-mode-list)) > > (setq viper-emacs-state-mode-list (cons > 'emacs-lisp-mode > viper-vi-state-mode-list)) > ;; alas edebug "print last eval" is still broken > > > (require 'edebug) > (edebug-instrument-function 'viper-adjust-undo) > > ;; a 1 > (execute-kbd-macro > [?a ?1 escape ?o ?2 escape])