Re: Bug in ZSH's vi emulation

[Daniel Shahaf <d.s@daniel.shahaf.name>]

Bart Schaefer wrote on Wed, Oct 05, 2016 at 10:19:38 -0700:
> On Oct 5, 10:09am, Ghjuvan' Lacambre wrote:
> }
> } 'd.' isn't a valid action as '.' is not a valid motion, yet 'd.' is
> } recorded as the last action called. When using '.', 'd.' will
> } recursively call itself
> 
> Confirmed.
> 
> Seems to be a problem with calling startvichange(1) before calling
> getvirange(), so the input is captured as a change event whether it
> succeeds or fails.  Unfortunately, I'm not familiar enough with the
> vi emulation code to see how to back out of startvichange().

Is it simply a matter of setting vichgbufptr to 0 if getvirange()
returns -1?  I've tried that; it fixes the problem and passes
tests.

Also here's a docs patch with my understanding some related globals.

diff --git a/Src/Zle/zle_vi.c b/Src/Zle/zle_vi.c
index baa2064..2cddea7 100644
--- a/Src/Zle/zle_vi.c
+++ b/Src/Zle/zle_vi.c
@@ -47,10 +47,19 @@ int vilinerange;
 
 /* last vi change buffer, for vi change repetition */
 
+/*
+ * vichgbufsz: Allocated size of vichgbuf.
+ * vichgbufptr: Length in use.
+ * vichgflag: true whilst inputting a vi normal mode; causes it to be
+ *   accumulated in vichgbuf, incrementing vichgbufptr.
+ */
+
 /**/
 int vichgbufsz, vichgbufptr, vichgflag;
 
 /*
+ * The bytes that make up the current vi command.  See vichgbuf* above.
+ *
  * Examination of the code suggests vichgbuf is consistently tied
  * to raw byte input, so it is left as a character array rather
  * than turned into wide characters.  In particular, when we replay