all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jim Meyering <jim@meyering.net>
To: Phillip Lord <phillip.lord@russet.org.uk>
Cc: 22295@debbugs.gnu.org, Michael Kifer <kifer@cs.stonybrook.edu>
Subject: bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14
Date: Sun, 15 May 2016 19:31:56 -0700	[thread overview]
Message-ID: <CA+8g5KHHB4qLty=9_30Hfwt79f-HrvE5hJnCY3qke8r05gzvOw@mail.gmail.com> (raw)
In-Reply-To: <87poso7nf5.fsf@russet.org.uk>

On Sat, May 14, 2016 at 6:57 AM, Phillip Lord
<phillip.lord@russet.org.uk> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Date: Sat, 14 May 2016 12:25:13 +0300
>>> From: Eli Zaretskii <eliz@gnu.org>
>>> Cc: 22295@debbugs.gnu.org, Jim Meyering <jim@meyering.net>
>>>
>>> > From: Jim Meyering <jim@meyering.net>
>>> > 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've got a complete test case (below in case anyone is interested --
> I'll make a proper unit test of it on master eventually).

Thank you for working on this. My fingers seem to have developed a
serious dependence on viper-mode over the last two decades.
I don't want to retrain them :-)





  parent reply	other threads:[~2016-05-16  2:31 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-03  4:01 bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14 Jim Meyering
2016-05-14  9:25 ` Eli Zaretskii
2016-05-14 10:01   ` Eli Zaretskii
2016-05-14 13:57     ` Phillip Lord
2016-05-14 20:10       ` Michael Kifer
2016-05-14 20:39         ` Phillip Lord
2016-05-14 20:50           ` Michael Kifer
2016-05-16  9:50             ` Phillip Lord
2016-05-17  3:38               ` Michael Kifer
2016-05-17  8:52                 ` Phillip Lord
2016-05-17 13:58                   ` Michael Kifer
2016-05-15  8:06           ` Michael Albinus
2016-05-16 12:37             ` Phillip Lord
2016-05-16 17:06               ` Michael Kifer
2016-05-16  2:31       ` Jim Meyering [this message]
2016-05-16 12:41         ` Phillip Lord
2016-05-16 15:39           ` Jim Meyering
2016-05-16 16:34             ` Eli Zaretskii
2016-05-16 17:14               ` Michael Kifer
2016-05-16 17:41                 ` Eli Zaretskii
2016-05-17  8:48                   ` Phillip Lord
2016-05-17  8:46                 ` Phillip Lord
2016-05-17 14:05                   ` Michael Kifer
2016-05-17 22:35                     ` Phillip Lord
2016-05-17  8:25               ` Phillip Lord
2016-05-17  8:35             ` Phillip Lord
     [not found]               ` <CA+8g5KG=XBCc8U3u3D=+bh74sMLAH9R7ZUZ=SeQL9de=WQ71vQ@mail.gmail.com>
2016-05-18  9:15                 ` Phillip Lord
2016-05-18 15:58                   ` Jim Meyering
2016-05-18 21:42                     ` Phillip Lord
2016-05-19  1:09                       ` Jim Meyering
2016-05-20 10:00                         ` Eli Zaretskii
2016-05-20 11:46                           ` Phillip Lord
2016-05-20 13:32                             ` Eli Zaretskii
2016-05-23  6:45                           ` John Wiegley
2016-05-23 13:23                             ` Phillip Lord
2016-05-24 15:43                               ` Eli Zaretskii
2016-05-25 12:43                                 ` Phillip Lord
2016-05-25 16:28                                   ` Eli Zaretskii
2016-06-01 13:06           ` Stefan Monnier
2016-06-01 22:23             ` Phillip Lord
2016-06-01 22:34               ` Michael Kifer
2016-06-01 22:41                 ` Phillip Lord
2016-06-01 22:47                   ` Michael Kifer
2016-06-02  0:11                 ` Stefan Monnier
2016-06-02  8:45                   ` Phillip Lord
2016-06-10 17:05               ` Stefan Monnier
2016-06-10 22:18                 ` Phillip Lord
2016-06-11  4:04                   ` Stefan Monnier
2016-06-13 12:36                     ` Phillip Lord
2016-06-11  7:34                   ` Eli Zaretskii
2016-06-13 12:37                     ` Phillip Lord
2016-06-13 13:06                       ` Stefan Monnier
2016-06-15  4:40                         ` Jim Meyering
2016-06-15  5:24                       ` Michael Kifer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+8g5KHHB4qLty=9_30Hfwt79f-HrvE5hJnCY3qke8r05gzvOw@mail.gmail.com' \
    --to=jim@meyering.net \
    --cc=22295@debbugs.gnu.org \
    --cc=kifer@cs.stonybrook.edu \
    --cc=phillip.lord@russet.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.