Allow to configure cursor keys for input fields

[serialprimate]

Version 1.29.1 Linux 64 bit

Consistency issue.

Steps to Reproduce:

1. Configure anything (e.g. Ctrl+B) for cursorLeft (Global)
2. Find all other conflicting key bindsings and remove them.
3. Observe that key works in an editor.
4. Open Search Bar (for example) or Find Widget (for another example) or search boxes.
5. Observe cursorLeft does not work in text boxes.

Only a finite subset of (generic named e.g cursor*, delete*) shortcuts are required if this is to be fixed. I do realise that sometimes these things can be tricky, especially if using stock widgets for these.

Does this issue occur when all extensions are disabled?: Yes

[jrieken]

Assuming @bpasero owns the InputBox

[ethanyu336]

yeah, I also want this,
configure binding in not only
Find Widget, but also in Quick Open,

[russelldavis]

I discovered a workaround: if you add "when": "textInputFocus" to the keybinding definition (run Open Keyboard Shortcuts (JSON) in the Command Pallete), these keybindings will start working in input fields.

So, the actual issue seems to be that certain keybindings without a when clause aren't truly global like they should be.

@bpasero it seems this should be labeled as bug rather than feature-request.

EDIT: That's not quite right. What's actually happening is that, without the when clause, vscode applies the cursor movement to the current editor rather than the focused input field. With the when clause, the custom binding doesn't actually apply at all (these input fields match inputFocus but not textInputFocus), and vscode falls back to a default behavior (probably the OS key bindings behavior), which in my case was close enough to what I was remapping it to that I hadn't noticed the difference.

So, my "workaround" is even less useful than I'd thought.

Also, any chance this can get some attention? It's been reported many times over the years:

#7433
#11950
#65578

[russelldavis]

(Was mistaken about the workaround, edited above.)

[eriegz]

Would love to get an update on this issue! This causes me daily frustration.

[serialprimate]

@bpasero It would also be cool if basic editing shortcuts were also consistent where they make sense. e.g. select, nav, delete etc. Not just cursor keys. The original intent was lost by your change of the request title in Dec 2018.

[ArturoDent]

Also see #175444

[alonso-herreros]

+1. I am getting used to alt+hjkl for navigation and this is a bit of a bummer.

[jcuffe]

+1 more, would appreciate the ability to rebind cursor navigation consistently across all widgets that display a cursor!

[gsisson]

+1 as I would also appreciate rebinding cursor nav keys in the findWidget. Frustrating that typing ^F ^B ^A ^E won't move the cursor as in emacs. I could swear it used to work fine for years, but now doesn't seem to work anymore. I tried to re-map the keys "when findWidgetVisible" and found that it doesn't work. Would be very nice to get fixed! Thanks!

[bobslee]

+1 Absolutely a necessity!
It's so misleading, inconsistent and frustrating those input keybindings can't be set.
Coming from Emacs made me really freaked out when experiencing this issue/lack.
I assume lots of devs experience this particular issue.