GNU bug report logs -
#22295
viper-mode undo bug introduced between Nov 10 and Nov 14
Previous Next
Reported by: Jim Meyering <jim <at> meyering.net>
Date: Sun, 3 Jan 2016 04:03:01 UTC
Severity: normal
Fixed in version 25.1
Done: phillip.lord <at> russet.org.uk (Phillip Lord)
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
>> Oh dear. Yes, that is a problem. The difficulty is that viper modifies
>> the undo-list, removing boundaries only *after* we leave insert mode.
I don't see any difficulty in there.
>> Viper's solution of introducing a 'viper symbol is a nice one, but has
>> it's problems.
Agreed.
>> primitive-undo: Unrecognized entry in undo list viper
> not in 25.0.50 viper worked fine with this for 20 years and I'd say
> it is Emacs breakage, not Viper's.
FWIW, Viper adds an entry to buffer-undo-list which is incompatible with
the documented format of the entries, so while it worked, Viper was
doing something unkosher.
In any case it shouldn't be difficult to fix that problem.
E.g. you could use
(defconst viper--undo-marker '(1 . 1))
instead of a symbol.
>> The deep problem here is that undo boundary == nil
I know you like to think of it as a problem ;-)
>> 1) Restore all the old viper code
>> 2) Instead of adding a 'viper mark, copy the buffer-undo-list to
>> "viper-old-buffer-undo-list".
Don't copy, just (setq viper--original-undo-list buffer-undo-list).
>> This is also quite a big change, and I worry about buffer compaction --
>> viper-old-buffer-undo-list would not be open for GC.
Why not?
This said, AFAIK the OP's problem may not be directly linked to the addition
of a special symbol in the undo-list. We should first figure out what's
actually going wrong there.
Stefan
This bug report was last modified 8 years and 346 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.