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

[Bart Schaefer <schaefer@brasslantern.com>]

On Jan 27, 12:43pm, Peter Stephenson wrote:
} Subject: Re: zle: vi mode: wrong undo handling on fresh lines
}
} On Sat, 25 Jan 2014 11:15:30 -0800
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} > 
} > Yes, I think it's a bug that completion doesn't behave as if you've
} > left and then re-entered insert mode.
} 
} So presumably startvichange() needs calling somewhere else?

I'm not sure that's exactly it, since we're already in insert mode ...

} 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.                                                      */

That's kind of related, I think.  A single undo should not cross over
the insertion point, so if we've moved that, we should have started a
new undo event.

} Maybe there needs to be a hook from the outside world.  

Either that or (shudder) we need vi- wrapped versions of the completion
widgets.

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

OH!  The problem seems to be that startvichange() always initializes
vichgbuf[0] = lastchar, and lastchar is still the trailing '\r' from
the previous command.  Is it safe to initialize lastchar = 0 when we
enter a new ZLE?