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 :-)
next prev 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.