modal editing in command mode

[alexherbo2]

:: enter in command-line, insert mode esc: leave to normal mode or quit the command-line when already in normal mode ctrl-c: quit the command-line

Example use case: :<esc>2K<ret>: execute 2 last commands :<esc>%stchou<ret><ret>: execute all previous commands matching tchou

[mawww]

Could you describe what you have in mind with more details ?

[jjthrash]

I agree with this one. Either modal editing for command lines, or some sort of basic emacs-style bindings. I often find the need to edit what I've typed in the command line, and I'm stuck with using arrow keys and backspace.

Allowing modal editing on the command line would keep the power, and the ctrl-c or double-escape seems like a sensible way to get out of the command line.

[davidaciko]

I would also like this.

[dumblob]

I also sometimes end up with the need to edit a longer command and have to use arrows in that case (for shorter commands, I simply delete everything up to the errorneous character). It should be enough to have just three non-modal shortcuts (these can be more complicated than the ones used during editing in the main window) for left, right, and remove_character (either to the left like backspace or to the right like delete - not necessarily both).

[mawww]

We already have <c-w>, <c-b> and <c-e> for word movements in the line editor. I was looking at <c-h> as an alias for <left>, <c-l> for <right> and <c-d> for <del> but <c-h> is already interpreted as backspace due to the terminal.

What would you like ? <a-h>, <a-l>, etc ?

[dumblob]

We already have <c-w>, <c-b> and <c-e> for word movements in the line editor.

Sorry, I missed this change...

What would you like ? <a-h>, <a-l>, etc ?

...and that means, that I'm perfectly ok with the current solution and don't want anything else to keep things KISS.

[mawww]

Well, I agree that having bindings for <left>/<right> that do not require to move the hand would be nice, its just that I started with control, and its too limited (for the same reason that most normal mode command would use alt rather than control).

What do you think about moving <c-w>, <c-b> and <c-e> to '<a-...>and add, <a-l> for <left>, <right> and <a-d> for <del> ?

[dumblob]

for the same reason that most normal mode command would use alt rather than control

Now you hit the nail head. I have to confess, that I'm working on alternative keybindins for those, who're using Alt_L and Alt_R for different, but higher-priority purposes like desktop management (including window management, menus, etc.). So my goal was simple - to remap the most important Alt-keybindings to something else (e.g. Ctrl-based bindings). In the last few months it got very difficult as few new bindings were added and there is no more any Ctrl-based shortcut available :(

This is also the reason, why I wanted to stay with the current solution <c-w>, <c-b> and <c-e>.

Why don't I stick to the original kak keybindings? Because I'm very much involved in design and creation of ergonomic HW and SW (in my case it's special new layouts which I and few other people are using for more than 4 years; now finally a HW keyboard and of course, the good old and horrible at the same time FVWM configuration with Alt-based everything).

I'm still convinced, that it's possible to devote one type of modifiers for each of these 3 fundamental layers (keybard with it's layout, then window/desktop management, and then the applications themself). For keyboard layout, I'm using Shifts, for extensive desktop mgmt Alts and for applications Ctrls. Let's see how will I solve the current situation with kak :)

[mawww]

Well, in my case I use the windows key for window management, so I keep alt free.

I do not find much difference between alt and ctrl for ease of use, but terminal input being what it is, there is no nice way to differentiate between <c-h> and <backspace> or <c-i> and <tab>.

That said, even though I would encourage people to use the default keybinding (and eventually ask me to change for something more sensible if available), its always nice to have the mapping system being tested out, as the default keybinding is very qwerty centric ({ being considered as shift-[ for example).

for the line edition, I'd really prefer to keep movement to a single modifier, either control or alt, if we want to add more that word movements, then alt would be easier as we get the whole keyboard available.

[dumblob]

there is no nice way to differentiate between and or and .

Could you be please a bit more specific? To my knowledge, escape sequences are evaluated on output (e.g. once they're echoed), but not on input (e.g. by pressing the relevant keyboard buttons).

as the default keybinding is very qwerty centric

Actually, to my experience (and experience of many others - e.g. from https://geekhack.org/), if the overall number of possible shortcuts is small and at the same time, the shortcuts have some semantic meaning (i.e. not related to layout, but rather to the characters themself), this is not an issue. That's why e.g. dvorak/colemak/whatever users can without any problems use Vim (or any other application) without any keybindings modifications.

for the line edition, I'd really prefer to keep movement to a single modifier, either control or alt, if we want to add more that word movements, then alt would be easier as we get the whole keyboard available.

In my opinion, this is not necessary - line commands are supposed to be short and thus only the three basic actions are essential.

[mawww]

there is no nice way to differentiate between and or and .

Could you be please a bit more specific? To my knowledge, escape sequences are evaluated on output (e.g. once they're echoed), but not on input (e.g. by pressing the relevant keyboard buttons).

I mean that when in a terminal emulator, <backspace> is sent as <c-h> and <tab> is sent as <c-i> so there is no way to have different mapping for these.

as the default keybinding is very qwerty centric

What I meant by that is that quite a few bindings on non alphabetic characters are based around the qwerty layout. For example all case manipulations are on and~because they happen to be on the same physical key in a qwerty layout. In a same way?is used for search expanding the selection because on a qwerty layout?isshift-/`. For these bindings, the logic behind their choice is based on the qwerty layout. However it is better to have a non layout dependent binding when possible. And I am definitely open to suggestions on default mapping improvements.

In my opinion, this is not necessary - line commands are supposed to be short and thus only the three basic actions are essential.

Do you mean you are fine with only word movements, using the <left> and <right> key for char movements ?

[dumblob]

And I am definitely open to suggestions on default mapping improvements.

I'll think about it - but I'm slow, so it might take me time to come up with something feasible (I'm always trying it first myself for a while and then eventually propose the change to others).

Do you mean you are fine with only word movements, using the <left> and <right> key for char movements ?

Actually, I'd prefer only character movements as word movements are less convenient for editing regexes etc. on command line (even longer inputs are not an issue as I'm using a quite high rate of repeating symbols when holding a button pressed).

[Delapouite]

related to https://github.com/mawww/kakoune/pull/800