I haven't noticed any issues with this while dogfooding it for the last two weeks, including both inside and outside of terminal, so it looks like I haven't broken the regular commands either.

Do we know how many vi testers we will have? If the concern is testing that nothing breaks outside of this mode, could we just have a few community maintainers use or merge this fork for themselves for a few weeks?

That bug was unfortunate, but I caught it fairly soon after the first two weeks --- I just didn't have time to fix it for a while. Otherwise I have been using this code consistently for several months and even outside of terminal, I haven't noticed any further issues. (At one point I thought I had a broken "clear line left" until I discovered that actually that was just not the correct command)

Do we know how many vi testers we will have? If the concern is testing that nothing breaks outside of this mode, could we just have a few community maintainers use or merge this fork for themselves for a few weeks?

One of the folks on the call did indeed say they'd do this. Hope we may be able to merge as soon as next weekend.

kitty

user and edit actions added by BlueDrinks PR #1885
Tested on Endeavour OS KDE Plasma

I'll post these as comments in the code if required.

extend doesn't make sense in a terminal/bash, since there's no no selection. I think redo doesn't have an action mapped by default if ctrl+r goes to rev search… but I'm not sure that's default, have you customised your shell at all?

cut and copy use the vi clipboard rather than system, no way around that. I'm not sure default readline bindings have a way to do it either; And regardless, I think you would prefer to have, cut and copy and paste all operate on the terminal selection rather than read line (i.e so you can copy text out of your terminal to the system clipboard)

extend doesn't make sense in a terminal/bash, since there's no no selection. I think redo doesn't have an action mapped by default if ctrl+r goes to rev search… but I'm not sure that's default, have you customised your shell at all?

$ bind -m vi-command -P | grep redo
vi-redo can be found on ".".
$ bind -m vi-insert -P | grep redo
vi-redo is not bound to any keys

Looks like it is only bound in command mode in bash by default. Undo is not bound in zsh's insert mode at all.

cut and copy use the vi clipboard rather than system, no way around that. I'm not sure default readline bindings have a way to do it either; And regardless, I think you would prefer to have, cut and copy and paste all operate on the terminal selection rather than read line (i.e so you can copy text out of your terminal to the system clipboard)

Some shells do indeed support a selection, but I agree it makes sense to use the system clipboard.

Looks like it is only bound in command mode in bash by default. Undo is not bound in zsh's insert mode at all.

vi-redo is not the same as a traditional redo, it's actually a repeat command. So no, there is no way to redo

Looks like it is only bound in command mode in bash by default. Undo is not bound in zsh's insert mode at all.

vi-redo is not the same as a traditional redo, it's actually a repeat command. So no, there is no way to redo

It does work as redo in zsh's vi command mode though.

"ctrl-r" does zsh redo, which it is what we have currently. "." does zsh repeat

Looks like it is only bound in command mode in bash by default. Undo is not bound in zsh's insert mode at all.

vi-redo is not the same as a traditional redo, it's actually a repeat command. So no, there is no way to redo

It does work as redo in zsh's vi command mode though.

"ctrl-r" does zsh redo, which it is what we have currently. "." does zsh repeat

Gotcha. Please add comments on expected behavior at the least since bash defaults to reverse i-search in either vi insert or command mode.

How's the comment I currently have?