contour
contour copied to clipboard
contour-terminal
vi input modes for visual select and yank/paste operations
Seems quite a hype lately, but I do see a use in that - as a vim user - to quickly search / reverse-search in the grid buffer for text fragments, visual-select them, and yank them into the clipboard or straight into stdin.
The first terminal that started adopting vi-like modes and motions was: Termite.
I think we'd need:
- [x] way to enter the mode
- [x] ability to move the vi-mode cursor around with h, j, k, l, but also page-wise up/down (Ctrl+d and Ctrl+u), paragraph wise up/down ({ and })
- [x] also be able to support attacking commands, such as
5k - [x] enter visual selection mode (and then support vim motions to block/line/char select the grid cells. v with/without mods)
- [x] yank the selection into clipboard or have it straight pasted back into stdin (or both)
- [x] exit visual selection mode (V)
- [x] exit vi-search mode (usually via Esc`)
- [x] visual motion/yank feedback on commands like
yy - [x] configurable color scheme & cursor shape per input mode.
- [x] config: ability to filter keybinds by new Vi modes to avoid shortcut conflicts.
It makes sense to put all this logic into its own class ViMode that can then be used by Terminal class, so it could be supported by any frontend (not just GUI frontend but also later on TUI, client/server, ... without any code duplication)
Non-Vim users will prefer customized key bindings, so it would be nice to have key bindings profiles. :)
Non-Vim users will prefer customized key bindings, so it would be nice to have key bindings profiles. :)
I think all of the above is possible, yeah. 👍
Vim users will also prefer keybind changing, much of the standard Vim keybinds are unwieldy and enUS-centric...
Vim users will also prefer keybind changing, much of the standard Vim keybinds are unwieldy and enUS-centric...
Except that the only challenging part may be action composition. things like 5j or 7{ are hardly configurable in VIM either. But I do see a really good fit for supporting the numeric modifiers. Well, if a non-vim user whants to bind the j or { (or whatever) to cursor keys etc, than composition should still work. I hope others might still find that feature useful :)
I'm not going to lie, I've really been wanting this feature available in terminals for large files for quite awhile. Editing them can be a huge pain when you're forced to scroll through huge chunks of code or text and potentially scroll right past it without realizing it. A search mode for vim would be an awesome extension. However, I think that functionality would be better added as a native component of vim itself.
Some other thoughts: Perhaps something could/should be implemented that all terminals can implement and would require manipulation of the screen/alternate screen so it wouldn't be just applicable to vim but other TUI text editors such as nano.
Yes, me too. But as much as I'd love to implement that, i have to wait doing so until after the next release, 0.2.0, otherwise i will never release :)
First, I think we should also support conventional arrow keys for moving around. Currently, arrow keys are forwarded to the underlying shell and do up-down in the history. Actually, forwarding anything to the underlying shell while in Vi-mode seems a bit weird... my cursor is in a random location, I press up or down arrow, and suddenly the prompt I've typed in changes...
In addition, I propose to changing the configuration file, because the current format is really, really wonky. We've got a normal_mode and a visual_mode top-level keys (relative to the profile), with only a comment explaining that these relate to Vim mode only... So people who do not know what Vim mode is, or do not care, will be weirded out by having these keys. We have complete control over the config file, so first there should be a vi: or vi-mode: or vim-mode: key under the profile, and then modes like normal and insert and such can be their own keys. And we save the _mode suffix this way.