Subject: Re: bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14

From: Stefan Monnier <[email-masked]>
Date: Wed, 01 Jun 2016 20:11:37 -0400

>> 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