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

[Bart Schaefer <schaefer@brasslantern.com>]

On Jan 29, 12:00am, Oliver Kiddle wrote:
} Subject: Re: zle: vi mode: wrong undo handling on fresh lines
}
} A non-blank starting line is possible with at least
} accept-line-and-down-history and vi-push-input. In such cases, it
} depends on the cursor position. If the cursor starts at the
} beginning of the line then 'i' makes more sense.
} 
} > Is it OK to assume we're not in insert mode when vi-repeat is executed?
} 
} Yes. Of course someone can bind a key to the widget but that currently
} just beeps which is fine.

Actually it does more than beep; with --

    bindkey -M viins '#' vi-repeat-change
    bindkey -v

-- type (whitespace added for clarity)

   xxx ESC a yyy #

and you end up with xxxyyya because # has repeated the "a" keystroke.
The yyy hasn't yet been added to the change buffer, so that doesn't get
repeated.  If you keep trying to use # from insert-mode (prior to the
patch in 32308), eventually it'll insert a "#", repeat carriage-return
and accept the buffer, probably resulting in a command-not-found.

} How about the following approach to the undo problem:
} The variable undoing was serving as a flag to indicate whether each
} change should be added as an undo event. In vi-mode this would be
} skipped so that the whole vi change became a single undo change. What
} this does is remove that handling and instead merge all the undo events
} corresponding to the vi change in the vi-cmd-mode widget.

This sounds fine to me, and wouldn't have been possible prior to the
numbering of undo events.  Is there a well-defined place where a user
defined widget could read $UNDO_CHANGE_NO and be sure it was the same
as the internal vistartchange value?
 
} Are there other ways to get into vi command mode besides vi-cmd-mode
} that might get around this?

One doc example for zle-line-init still implies you can get into vi
command mode by "zle -K vicmd".  (This even moves one character left
when switching from viins to vicmd; I'm not sure how/where the code
that does that is being called.)