Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Bug in ZSH's vi emulation

Daniel Shahaf wrote:
> > 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

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

Not really. If we want a quick fix for 5.3 then either that or checking
virangeflag at the top of virepeatchange will do the job.

For a correct vi compatible fix, anything that causes the widget -
vi-delete or whatever to return failure should abort the vi change
and the previous value of vichgbuf should be restored. So most
occurences of vichgflag = 0 could change to call a new endvichange() which
would do the restore. Or that might be factored out into the caller.

I'm also pondering the interaction with user-defined widgets.
Note that from vi, with a key mapping of :nmap \d dwdw
Then, \d followed by dot will remove three words not four.
dot only repeats the final change. In practice this isn't especially
useful so things like the repeat.vim plugin exist. I'm not sure
that we should even strive for vi compatibility here but I think
we're missing some logic in cases where calls to startvichange occur
as part of a user-defined widget.

We've also got a separate issue of only lastchar being stuffed into
vichgbuf so repeating, e.g. gU doesn't work. Why is keybuflen only
1 in startvichange? That, along with what the general point of lastchar
is, has me fairly puzzled.


Messages sorted by: Reverse Date, Date, Thread, Author