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: Mon, 16 May 2016 13:14:05 -0400 Message-ID: <5739FFDD.8080206@cs.stonybrook.edu> References: <83vb2h6lfq.fsf@gnu.org> <83r3d56jrg.fsf@gnu.org> <87poso7nf5.fsf@russet.org.uk> <878tzatbte.fsf@russet.org.uk> <83zirq3qt4.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1463418961 31942 80.91.229.3 (16 May 2016 17:16:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 May 2016 17:16:01 +0000 (UTC) Cc: 22295@debbugs.gnu.org, phillip.lord@russet.org.uk To: Eli Zaretskii , Jim Meyering Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon May 16 19:15:45 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 1b2M6w-0001Rp-02 for geb-bug-gnu-emacs@m.gmane.org; Mon, 16 May 2016 19:15:18 +0200 Original-Received: from localhost ([::1]:45106 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2M6v-0007Q8-Du for geb-bug-gnu-emacs@m.gmane.org; Mon, 16 May 2016 13:15:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55862) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2M6m-000792-MB for bug-gnu-emacs@gnu.org; Mon, 16 May 2016 13:15:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b2M6g-0005nY-8H for bug-gnu-emacs@gnu.org; Mon, 16 May 2016 13:15:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41734) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2M6g-0005nA-29 for bug-gnu-emacs@gnu.org; Mon, 16 May 2016 13:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1b2M6f-0003Ws-Tc for bug-gnu-emacs@gnu.org; Mon, 16 May 2016 13:15: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: Mon, 16 May 2016 17:15: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.146341885313486 (code B ref 22295); Mon, 16 May 2016 17:15:01 +0000 Original-Received: (at 22295) by debbugs.gnu.org; 16 May 2016 17:14:13 +0000 Original-Received: from localhost ([127.0.0.1]:54071 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b2M5t-0003VR-6J for submit@debbugs.gnu.org; Mon, 16 May 2016 13:14:13 -0400 Original-Received: from mail-qk0-f178.google.com ([209.85.220.178]:35725) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b2M5r-0003VB-L8 for 22295@debbugs.gnu.org; Mon, 16 May 2016 13:14:11 -0400 Original-Received: by mail-qk0-f178.google.com with SMTP id n62so88298023qkc.2 for <22295@debbugs.gnu.org>; Mon, 16 May 2016 10:14:11 -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=8h6G382IpE9U4d4UQXAmLKx60ReIYtkpnA5Pr2pAVA4=; b=kTNB1mzY8cyYx4udCVcPLJQIji1x/eTPx/TUcyUoQFiIbNwx/gG7UGKXy+ZiW6oKtm ovCJtb73nkXItMDE9fPuZmKpQszPEIfYHbFzIBbvErY/bUKWZgEfepILLuDffxnkubKH QlaqKQAeEdvbD8kmdumOgonGfbTQV9ya+4Lf5Rb0TLDhLgmHBFww0q7ih6qOP5HIIb7Y nj8rMyncpqvVE38XbYkmAqN4qc3vbr+Am+m+SFBnYaj2SoBwelOlFpt0D58zbtjyDVqK tKLSSVjsenM95BGDuL8TUGo2IegvA+Ek4WmQMDucyD82j4azuheZ1okxyEXAYH3EorI9 HeIg== 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=8h6G382IpE9U4d4UQXAmLKx60ReIYtkpnA5Pr2pAVA4=; b=gMi1R1wzDB0IZN8uJtTNeTMZ7vKrq1NCDAuA0a0pqaJGVhy3ukfYI9/1FN52TjaSWN oP8fF1WUr9wdxr4SL10c7LFbDJaWaK6hVb5HMt4zJ+Ll8Uy1B194A+EaXWcdFjwkUjWE LqRUjVctyZnCXoUHgRryiOh4QZZzXTOZZWrZVPhaZEK6vfSdAZxsh5mEYY74il4LEV6U kQbDkVooU5JXrFcrgONg8zvI5Tm50sFzJNx7qrrN6n6xyWd5vBOtoqDfRnMnoL6spoXa nTZyZ65/ggNmdSj6MAPjPlvl+fs18Ww+ciHri9TaErB4r4AX0BH13/jvgGhasbuzLCEG XA5w== X-Gm-Message-State: AOPr4FVCAzukUbkrKtLh6q0+uyOWeDCOdhCjJtYnT147gQy2GVW2sy7Kj6d9frizydNtMG7U X-Received: by 10.55.15.102 with SMTP id z99mr26641848qkg.209.1463418846245; Mon, 16 May 2016 10:14:06 -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 w110sm15143194qge.43.2016.05.16.10.14.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 May 2016 10:14:05 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 In-Reply-To: <83zirq3qt4.fsf@gnu.org> 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:118296 Archived-At:

On 05/16/2016 12:34 PM, Eli Zaretskii wrote:
From: Jim Meyering <jim@meyering.net>
Date: Mon, 16 May 2016 08:39:15 -0700
Cc: Eli Zaretskii <eliz@gnu.org>, Michael Kifer <kifer@cs.stonybrook.edu>, 22295@debbugs.gnu.org

Thank you.
That does indeed fix the case I mentioned.
Here are some cases where it does not work as expected:

  start with an empty buffer in viper-mode
  type 'i 1 2 3 4 5ESC'
  type 'F2dw' to delete the 2 and a space.
  type 'wdw' to delete the 4 and a space.

Now, if I were to hit "u" to undo, I would expect that most recent
deletion to be undone and the 4 would reappear.
Then I would hit '.' to undo the deletion of the '2'. Finally one more
'.' would undo the creation of that first line.
However, with the current patches, that first 'u' undoes everything
and leaves me with the empty initial file.

Another example starting with an empty file:
Create some content via ':r!seq 999|fmt RETURN'
Then remove e.g., "222 " and "444 " via '/222' RET 'dw',
then '/444' RET 'dw'. Now, we expect a single 'u' to restore the '444 ',
yet it undoes everything, leaving an empty buffer.
Hmm... that's probably no different from the first example.

One more, then. Starting with this input:

  1 2 3 4 5 6

advance to the '2' with 'w', 'dw' to delete the 2, then three '.'s to
delete the 3, then 4 and 5.
Then begin to undo with 'u', then '.' to repeat it. Those first two
work, restoring the 5 and 4.
However, one more '.' restores both the 3 and the 2.

Thanks.  It now looks like your expectations are close to what Emacs
does by default, whereas Michael said the VI undo is more coarse (and
in the original recipe, it indeed seemed to be that).

Is it possible to have a more general/formal description of what
'undo' in VI is supposed to do?  E.g., it looks like it has different
granularities wrt insertions and deletions, is that correct?

You see, when I said this is undocumented, I meant precisely that: the
expected effect of 'undo' in VI is not described, so someone who is
not a VI user doesn't know what to test and how to program that.

In VI, an undo is supposed to undo the effect of the previous VI command.  In Emacs terms, each such command usually means several inserts and deletes, which in Emacs would be undone via a series of undos. Such behavior is a non-no to a vi user.

Michael said that this _is_ documented, but the only documentation I
see is comments that describe _what_ they do in terms of Emacs undo
structures, and are full of "rationale" such as "so that things will
be undone properly".  I don't see any description of the expected
effect of undoing in different situations, let alone some formal
specification of undo-related requirements.  If I missed some
description of how undo is supposed to work in viper, please just
point me there.

I was referring to the insertion of a special marker into the undo list. Obviously, the usual Vi conventions are not documented because this would require to duplicate the Vi manual.

Another alternative is to make viper use the default Emacs undo, and
then ask you and other users of viper to tell where the results don't
match your expectations.  It could well be that starting with a clean
slate will get us to the goal faster and with less complex code.

This would be a non-starter and would cause a mass migration to vim. The undo would also then be implementation dependent.  If, say, "delete 2 words" is implemented differently from how it is now then it would  be undone via a different sequence of commands.

--

       --- michael