Re: zle: vi mode: wrong undo handling on fresh lines

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

On Sat, 25 Jan 2014 11:15:30 -0800
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Jan 25, 12:19am, Oliver Kiddle wrote:
> }
> } I find the effect of this change to undo to be very annoying. Typically
> } undo now wipes the whole buffer which isn't much use. In particular, the
> } old behaviour of undo after a completion is important to me. I
> } understand that it rightly should be marking the start of an insertion
> } at this point.
> 
> Yes, I think it's a bug that completion doesn't behave as if you've
> left and then re-entered insert mode.  That's a bit different than what
> you mentioned about the vim behavior.

So presumably startvichange() needs calling somewhere else?  It's not
clear where, since it's only used inside zle_vi.c, which has nothing to
do with completion.  Maybe there needs to be a hook from the outside
world.  There is some interaction with completion in the top-level
docomplete() call:

    /* For vi mode, reset the start-of-insertion pointer to the beginning *
     * of the word being completed, if it is currently later.  Vi itself  *
     * would never change the pointer in the middle of an insertion, but  *
     * then vi doesn't have completion.  More to the point, this is only  *
     * an emulation.                                                      */
    if (viinsbegin > ztrsub(zlemetaline + wb, zlemetaline))
	viinsbegin = ztrsub(zlemetaline + wb, zlemetaline);

but that doesn't look like it's relevant here.  The only other mention
down there that I can see is when expanding history, which is a
different matter.

> } However, even aside from that, the change doesn't seem to
> } be quite right: e.g. vi-repeat (dot) can't repeat the initial insertion.
> 
> Worse than that, vi-repeat forllowing the initial insertion repeats
> the accept-line from the end of the previous command, thus attempting
> to execute the (usually partial) current command line immediately.
> 
> Clearly more is needed to properly set up the vi-mode state at the start
> of the buffer.

That kind of suggests there's some stuff startvitext() or
startvichange() ought to be doing already but isn't, but we've got away
with it somehow.  inrepeat and vichgrepeat presumably have something to
do with it.

I'm not going to be much use smoothing out all the wrinkles, since I
never use vi mode.

pws