GNU bug report logs - #22295
viper-mode undo bug introduced between Nov 10 and Nov 14

Previous Next

Full log

Message #70 received at 22295 <at> debbugs.gnu.org (full text, mbox):

From: phillip.lord <at> russet.org.uk (Phillip Lord)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Kifer <kifer <at> cs.stonybrook.edu>, 22295 <at> debbugs.gnu.org,
 jim <at> meyering.net
Subject: Re: bug#22295: viper-mode undo bug introduced between Nov 10 and Nov
 14
Date: Tue, 17 May 2016 09:48:20 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: phillip.lord <at> russet.org.uk, 22295 <at> debbugs.gnu.org
>> From: Michael Kifer <kifer <at> cs.stonybrook.edu>
>> Date: Mon, 16 May 2016 13:14:05 -0400
>> 
>> >  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. 
>
> Then I guess the current trial-and-error method will have to be the
> way.  Too bad, I have hard time believing we will be ready with a
> complete solution in time for Emacs 25.1, which is what I hoped.

I worry about this as well. I still do not understand why my changes
have caused this problem; I'd rather not be taking the approach to
redoing the implementation of viper during release candidate.

Still, if, as I suspect, it's because the timing of boundaries has
changed slightly, it's likely to be the only choice.

Phil

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.