From: phillip.lord@russet.org.uk (Phillip Lord)
To: Eli Zaretskii <eliz@gnu.org>
Cc: Michael Kifer <kifer@cs.stonybrook.edu>,
22295@debbugs.gnu.org, jim@meyering.net
Subject: bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14
Date: Sat, 14 May 2016 14:57:02 +0100 [thread overview]
Message-ID: <87poso7nf5.fsf@russet.org.uk> (raw)
In-Reply-To: <83r3d56jrg.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 14 May 2016 13:01:23 +0300")
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).
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])
next prev parent reply other threads:[~2016-05-14 13:57 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 [this message]
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
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87poso7nf5.fsf@russet.org.uk \
--to=phillip.lord@russet.org.uk \
--cc=22295@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=jim@meyering.net \
--cc=kifer@cs.stonybrook.edu \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).