Adding multiple elements to a "keys" list under "keybindings" causes the entire binding to be discarded #3346

Closed
opened 2026-01-30 23:19:13 +00:00 by claunia · 4 comments
Owner

Originally created by @pickscrape on GitHub (Aug 10, 2019).

Environment

Windows build number: Microsoft Windows [Version 10.0.18362.267]
Windows Terminal version (if applicable): 0.3.2171.0

Any other software?

Steps to reproduce

  1. Edit config.
  2. For any keybinding, add an additional key definition to the "keys" list.
  3. Close and re-open Terminal
  4. See that the entire command has been removed from the "keybindings" section of the config

In my case, I was trying to add shift+insert as an additional paste keybinding. At first, I though the problem was an incorrect key specification on my part, but using "shift+insert" as the sole keybinding worked fine.

Expected behavior

At the very least, I would expect both the keybinding element, and the first item in the "keys" list, to be maintained.

Ideally, all keybindings in the list would work to activate the function (assuming no conflicts with keybindings in other functions).

Actual behavior

The entire keybinding element is removed

Originally created by @pickscrape on GitHub (Aug 10, 2019). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Environment ```none Windows build number: Microsoft Windows [Version 10.0.18362.267] Windows Terminal version (if applicable): 0.3.2171.0 Any other software? ``` # Steps to reproduce 1. Edit config. 1. For any keybinding, add an additional key definition to the "keys" list. 1. Close and re-open Terminal 1. See that the entire command has been removed from the "keybindings" section of the config In my case, I was trying to add shift+insert as an additional paste keybinding. At first, I though the problem was an incorrect key specification on my part, but using "shift+insert" as the sole keybinding worked fine. # Expected behavior At the very least, I would expect both the keybinding element, and the first item in the "keys" list, to be maintained. Ideally, all keybindings in the list would work to activate the function (assuming no conflicts with keybindings in other functions). # Actual behavior The entire keybinding element is removed
claunia added the Issue-QuestionNeeds-TriageArea-SettingsResolution-Answered labels 2026-01-30 23:19:13 +00:00
Author
Owner

@DHowett-MSFT commented on GitHub (Aug 10, 2019):

So this is pretty interesting. The right way to add multiple bindings for the same event is to duplicate the entire binding -- that is:

{command: "x", keys: [ "y" ]},
{command: "x", keys: [ "z" ]},

multiple keys in the keys array are actually for key chording, like "Ctrl+B followed by E". That's not actually supported today, it's just aspirational.

@DHowett-MSFT commented on GitHub (Aug 10, 2019): So this is pretty interesting. The right way to add multiple bindings for the same event is to _duplicate the entire binding_ -- that is: ``` {command: "x", keys: [ "y" ]}, {command: "x", keys: [ "z" ]}, ``` multiple keys in the `keys` array are actually for key _chording_, like "<kbd>Ctrl+B</kbd> followed by <kbd>E</kbd>". That's not _actually_ supported today, it's just aspirational.
Author
Owner

@pickscrape commented on GitHub (Aug 10, 2019):

Oh! Well, that makes sense now that I know it, but it wasn't clear to me at all.

I'm not sure where I should have gone to find that out myself?

@pickscrape commented on GitHub (Aug 10, 2019): Oh! Well, that makes sense now that I know it, but it wasn't clear to me at all. I'm not sure where I should have gone to find that out myself?
Author
Owner

@DHowett-MSFT commented on GitHub (Aug 12, 2019):

We could definitely document this better. It'll work a lot better once #1334 is done, though. 😄 Sorry about that.

@DHowett-MSFT commented on GitHub (Aug 12, 2019): We could definitely document this better. It'll work a lot better once #1334 is done, though. :smile: Sorry about that.
Author
Owner

@0xabu commented on GitHub (Sep 19, 2019):

I just came here to note that I made the same assumption/mistake at the original submitter. I've never encountered a terminal that used chorded key bindings before (surely there will never be so many actions in a terminal?), so didn't even consider the possibility.

Given that multiple bindings are effectively broken at the moment anyway (#2389) might this design choice be worth revisiting?

@0xabu commented on GitHub (Sep 19, 2019): I just came here to note that I made the same assumption/mistake at the original submitter. I've never encountered a terminal that used chorded key bindings before (surely there will never be so many actions in a terminal?), so didn't even consider the possibility. Given that multiple bindings are effectively broken at the moment anyway (#2389) might this design choice be worth revisiting?
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#3346