Unexpected keybinding config error #6969

Closed
opened 2026-01-31 00:51:51 +00:00 by claunia · 10 comments
Owner

Originally created by @nurbles on GitHub (Mar 18, 2020).

Environment

Windows build number: [Version 10.0.18363.720]
Windows Terminal version (if applicable): 0.10.761.0

Any other software? not sure what this is asking

Steps to reproduce

This is happening any time I start terminal -- not a new tab in terminal, but starting the very first terminal window.

Expected behavior

I expect the window to open as it had done earlier in the day -- without popping an error message.

Actual behavior

All of a sudden (from my point of view) starting up terminal presented me with an "Encountered errors while loading user settings" message (I will try to attach a screen shot of the message and a copy of my settings json file). The thing is, I have been working with VS2019, my own software, notepad++, outlook and other stuff all day, with most things (especially terminal) being started and stopped multiple times. I have not even looked at the settings for anything, so there is no reason for them to have changed -- I never did it myself, nor did I authorize anything else to do it for me. My system has not rebooted, though God only knows what Windows Update may have done in the background without telling me...
terminal-error
profiles.json.txt

Originally created by @nurbles on GitHub (Mar 18, 2020). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 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: [Version 10.0.18363.720] Windows Terminal version (if applicable): 0.10.761.0 Any other software? not sure what this is asking ``` # Steps to reproduce This is happening any time I start terminal -- not a new tab in terminal, but starting the very first terminal window. <!-- A description of how to trigger this bug. --> # Expected behavior I expect the window to open as it had done earlier in the day -- without popping an error message. <!-- A description of what you're expecting, possibly containing screenshots or reference material. --> # Actual behavior All of a sudden (from my point of view) starting up terminal presented me with an "Encountered errors while loading user settings" message (I will try to attach a screen shot of the message and a copy of my settings json file). The thing is, I have been working with VS2019, my own software, notepad++, outlook and other stuff all day, with most things (especially terminal) being started and stopped multiple times. **I** have not even __looked__ at the settings for anything, so there is no reason for them to have changed -- I never did it myself, nor did I authorize anything else to do it for me. My system has not rebooted, though God only knows what Windows Update may have done in the background without telling me... ![terminal-error](https://user-images.githubusercontent.com/14079927/76994625-095cbb00-6925-11ea-953f-c4d316d8abd7.png) [profiles.json.txt](https://github.com/microsoft/terminal/files/4350682/profiles.json.txt) <!-- What's actually happening? -->
claunia added the Issue-QuestionNeeds-Tag-FixResolution-Answered labels 2026-01-31 00:51:51 +00:00
Author
Owner

@DHowett-MSFT commented on GitHub (Mar 18, 2020):

It looks like your profiles.json file has contained some invalid settings for a while, and the new version of Terminal is correctly calling those invalid settings out.

      "keybindings": [
        {
          "command": "closePane",
          "keys": [
            "shift+f4",
            "ctrl+shift+w"
          ]
        },
        {
          "command": "copy",
          "keys": [
            "ctrl+ins",
            "ctrl+shift+c"
          ]
        },

An entry in "keybindings" cannot have multiple keys. That feature is intended for key chording, such that you can configure "shift+f4 ctrl+shift+w" in sequence to trigger closePane.

I have not even looked at the settings for anything

Terminal has never shipped a settings file with multiple keys set for the same action, so I'm going to say that some software on your system must have made this change.

Incidentally, your settings file looks like it's very old (pre-version-0.5). The eminent Scott Hanselman wrote up a good blog post on why it might be a good time to start anew.

@DHowett-MSFT commented on GitHub (Mar 18, 2020): It looks like your profiles.json file has contained some invalid settings for a while, and the new version of Terminal is correctly calling those invalid settings out. ``` "keybindings": [ { "command": "closePane", "keys": [ "shift+f4", "ctrl+shift+w" ] }, { "command": "copy", "keys": [ "ctrl+ins", "ctrl+shift+c" ] }, ``` An entry in "keybindings" cannot have _multiple `keys`_. That feature is intended for key chording, such that you can configure "shift+f4 ctrl+shift+w" in sequence to trigger `closePane`. > I have not even looked at the settings for anything Terminal has never shipped a settings file with multiple keys set for the same action, so I'm going to say that some software on your system must have made this change. Incidentally, your settings file looks like it's very old (pre-version-0.5). The eminent Scott Hanselman wrote up a [good blog post](https://www.hanselman.com/blog/NowIsTheTimeToMakeAFreshNewWindowsTerminalProfilesjson.aspx) on why it might be a good time to start anew.
Author
Owner

@nurbles commented on GitHub (Mar 18, 2020):

Thanks for the info.

I may have added those extra bindings at the direction of a post here. It is unlikely that I 'invented' them myself. (As a rule, I try to avoid directly looking at JSON files almost as much as I avoid XML -- I don't want to go blind!) I remember making a couple changes to the default shell, the font and default rows/columns, but I don't remember doing anything more. I might have, but I don't remember.

As for "starting anew" ... that's the kind of thing I tend to trust the application updates to take care of, even if they need to ask me for "assistance" in what to keep, lose or change.

I guess the error just "appeared" because terminal was silently updated by Windows Update (or something like it) between two runs of the program today. Gotta love it, I suppose -- do I have a choice?

@nurbles commented on GitHub (Mar 18, 2020): Thanks for the info. I may have added those extra bindings at the direction of a post here. It is unlikely that I 'invented' them myself. (As a rule, I try to avoid directly looking at JSON files almost as much as I avoid XML -- I don't want to go blind!) I remember making a couple changes to the default shell, the font and default rows/columns, but I don't remember doing anything more. I might have, but I don't remember. As for "starting anew" ... that's the kind of thing I tend to trust the application updates to take care of, even if they need to ask me for "assistance" in what to keep, lose or change. I guess the error just "appeared" because terminal was silently updated by Windows Update (or something like it) between two runs of the program today. Gotta love it, I suppose -- do I have a choice?
Author
Owner

@DHowett-MSFT commented on GitHub (Mar 18, 2020):

I'd love for us to be able to take care of "starting anew" for you, but this is one of those cases where we explicitly decided that the user's settings file was their property and not ours. We used to touch it a whole bunch, to add and remove things, and that didn't end up being very scalable (or pleasant for anyone!)

Alas, quiet automatic updates are the Store's doing. Sorry about that.

@DHowett-MSFT commented on GitHub (Mar 18, 2020): I'd love for us to be able to take care of "starting anew" for you, but this is one of those cases where we explicitly decided that the user's settings file was _their property_ and not ours. We used to touch it a whole bunch, to add and remove things, and that didn't end up being very scalable (or pleasant for anyone!) Alas, quiet automatic updates are the Store's doing. Sorry about that.
Author
Owner

@nurbles commented on GitHub (Mar 19, 2020):

So, are there any instructions or documentation for this "starting anew" procedure? I would guess that the best way should be to uninstall and then reinstall, but since so few programs actually clean any old stuff out during either of those processes, I have little hope that would work.

Related to the error message: It was VERY surprising that I was able to type commands BEHIND the error popup! Apparently the error does not have the keyboard focus, even though the different brightness levels of the shell and error seem to indicate otherwise. I think THAT is an actual bug.

FWIW, I like the terminal for a simple reason: it loads faster than CMD while still supporting (most of) the things I did with CMD. I am not interested in hacking away (and learning a whole new language in the process) directly within a JSON configuration file. I do everything I can to avoid JSON (and XML).

@nurbles commented on GitHub (Mar 19, 2020): So, are there any instructions or documentation for this "starting anew" procedure? I would guess that the best way _should_ be to uninstall and then reinstall, but since so few programs actually clean any old stuff out during either of those processes, I have little hope that would work. Related to the error message: It was VERY surprising that I was able to type commands BEHIND the error popup! Apparently the error does not have the keyboard focus, even though the different brightness levels of the shell and error seem to indicate otherwise. I think THAT is an actual bug. FWIW, I like the terminal for a simple reason: it loads faster than CMD while still supporting (most of) the things I did with CMD. I am not interested in hacking away (and learning a whole new language in the process) directly within a JSON configuration file. I do everything I can to avoid JSON (and XML).
Author
Owner

@nurbles commented on GitHub (Mar 19, 2020):

OK, I started "anew" by renaming profiles.json and restarting terminal. Then I moved over the few things I changed (font face/size, rows/columns, default shell). Works great. I have been reading the docs about the configuration file and came across this line about key bindings:

This is an array of key chords and shortcuts to invoke various commands. Each command can have more than one key binding.

This appears to directly conflict with your earlier statement that only one binding is allowed. Given the error message, perhaps the documentation should be corrected to reflect the (new?) reality.

The quote may be found just after Key Bindings on this page: UsingJsonSettings

Thanks again for all your help and to everyone working on this nifty tool!

@nurbles commented on GitHub (Mar 19, 2020): OK, I started "anew" by renaming profiles.json and restarting terminal. Then I moved over the few things I changed (font face/size, rows/columns, default shell). Works great. I have been reading the docs about the configuration file and came across this line about key bindings: > This is an array of key chords and shortcuts to invoke various commands. Each command can have more than one key binding. This appears to directly conflict with your earlier statement that only one binding is allowed. Given the error message, perhaps the documentation should be corrected to reflect the (new?) reality. The quote may be found just after **Key Bindings** on this page: [UsingJsonSettings](https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingJsonSettings.md) Thanks again for all your help and to everyone working on this nifty tool!
Author
Owner

@zadjii-msft commented on GitHub (Mar 19, 2020):

@nurbles No, that documentation is actually saying what we want there. You can have multiple keys bound to the same action, but they should each be in their own bindings. For example:


    "keybindings" :
    [
        { "command": "copy", "keys": ["ctrl+shift+c"] },
        { "command": "copy", "keys": ["ctrl+c"] },
        { "command": "copy", "keys": ["enter"] },
        { "command": "paste", "keys": ["shift+insert"] },
        { "command": { "action": "splitPane", "split":"auto", "splitMode": "duplicate" }, "keys": [ "ctrl+alt+t" ] }
    ]

In this snippet from my keybindings, all three of ctrl+shift+c, ctrl+c and enter are bound to copy

@zadjii-msft commented on GitHub (Mar 19, 2020): @nurbles No, that documentation is actually saying what we want there. You can have multiple keys bound to the same action, but they should each be in their own bindings. For example: ```json "keybindings" : [ { "command": "copy", "keys": ["ctrl+shift+c"] }, { "command": "copy", "keys": ["ctrl+c"] }, { "command": "copy", "keys": ["enter"] }, { "command": "paste", "keys": ["shift+insert"] }, { "command": { "action": "splitPane", "split":"auto", "splitMode": "duplicate" }, "keys": [ "ctrl+alt+t" ] } ] ``` In this snippet from my keybindings, all three of <kbd>ctrl+shift+c</kbd>, <kbd>ctrl+c</kbd> and <kbd>enter</kbd> are bound to `copy`
Author
Owner

@nurbles commented on GitHub (Mar 19, 2020):

Ah-ha! Thanks for the clarification. Also, thank's for allowing comments in terminal's JSON file! They are super helpful to remind me how the bits work and what I changed, since I almost never look at the thing.

@nurbles commented on GitHub (Mar 19, 2020): Ah-ha! Thanks for the clarification. Also, thank's for allowing comments in terminal's JSON file! They are super helpful to remind me how the bits work and what I changed, since I almost never look at the thing.
Author
Owner

@nurbles commented on GitHub (Mar 20, 2020):

Just curious... Why does terminal allow multiple bindings for each key, but only defined as a set of separate definitions with an array of bindings that only ever has ONE element? Since I'm being forced to learn about JSON in order to make sure my configuration changes are correct, everything I have found says that the
{ "command": "copy", "keys": ["ctrl+shift+c"] },
syntax is defining an array of "keys" for the "commnd":"copy", but terminal only allows one element in the array. Then this is even more strange:
{ "command": "copy", "keys": ["ctrl+shift+c"] }, { "command": "copy", "keys": ["ctrl+c"] }, { "command": "copy", "keys": ["enter"] },
This is defining a set of three different keys (and chords) for the command copy by using THREE ARRAYS with ONE ELEMENT each! It seems to me that if you are going to use JSON, you might as well actually use it in the way it is defined instead of having a strange restriction like this. I have not tried it yet, but the documentation says that the one element arrays OR non-array settings may be used -- so all the square brackets above could be removed. So I think the documentation (and any sample JSON file(s)) should NOT use the array format when more than one value is not allowed. That's just confusing.

(Sorry about the lack of CR/LF on the second example. I tried numerous ways to get this things to allow it, but it refused.)

@nurbles commented on GitHub (Mar 20, 2020): Just curious... Why does terminal allow multiple bindings for each key, but only defined as a set of separate definitions with an array of bindings that only ever has ONE element? Since I'm being forced to learn about JSON in order to make sure my configuration changes are correct, everything I have found says that the ` { "command": "copy", "keys": ["ctrl+shift+c"] }, ` syntax is defining an array of "keys" for the "commnd":"copy", but terminal only allows one element in the array. Then this is even more strange: ` { "command": "copy", "keys": ["ctrl+shift+c"] }, { "command": "copy", "keys": ["ctrl+c"] }, { "command": "copy", "keys": ["enter"] }, ` This is defining a set of three different keys (and chords) for the command copy by using THREE ARRAYS with ONE ELEMENT each! It seems to me that if you are going to use JSON, you might as well actually use it in the way it is defined instead of having a strange restriction like this. I have not tried it yet, but the documentation says that the one element arrays OR non-array settings may be used -- so all the square brackets above could be removed. So I think the documentation (and any sample JSON file(s)) should NOT use the array format when more than one value is not allowed. That's just confusing. (Sorry about the lack of CR/LF on the second example. I tried numerous ways to get this things to allow it, but it refused.)
Author
Owner

@zadjii-msft commented on GitHub (Mar 20, 2020):

There's not a great reason here. Basically, we knew that one day, we'd like to support keychords with multiple keystrokes in them, like pressing Ctrl+B,Ctrl+1 to do an action. Since we knew we'd one day need multiple keys in the array, we made it an array to begin with.

Then we realized

  1. We're not going to be able to do chords like this before 1.0
  2. We can trivially parse the JSON differently for a single string value vs an array value

So older versions of the settings file will have an array for the keys property, while newer versions will just use a string, like

    "keybindings" :
    [
        { "command": "copy", "keys": "ctrl+shift+c" },
        { "command": "copy", "keys": "ctrl+c" },
        { "command": "copy", "keys": "enter" },
        { "command": "paste", "keys": "shift+insert" },
        { "command": { "action": "splitPane", "split":"auto", "splitMode": "duplicate" }, "keys": "ctrl+alt+t" }
    ]

Both this and the snippet I have above are treated the same way.


PS: markdown protip: you can use "code fences" to have multiple lines of code in your comments. By using something like:

```
This is code
With multiple lines
```

You can get content that looks like

This is code
With multiple lines
@zadjii-msft commented on GitHub (Mar 20, 2020): There's not a _great_ reason here. Basically, we knew that one day, we'd like to support keychords with multiple keystrokes in them, like pressing <kbd>Ctrl+B</kbd>,<kbd>Ctrl+1</kbd> to do an action. Since we knew we'd _one day_ need multiple keys in the array, we made it an array to begin with. Then we realized 1. We're not going to be able to do chords like this before 1.0 2. We can trivially parse the JSON differently for a single string value vs an array value So older versions of the settings file will have an array for the `keys` property, while newer versions will just use a string, like ```json "keybindings" : [ { "command": "copy", "keys": "ctrl+shift+c" }, { "command": "copy", "keys": "ctrl+c" }, { "command": "copy", "keys": "enter" }, { "command": "paste", "keys": "shift+insert" }, { "command": { "action": "splitPane", "split":"auto", "splitMode": "duplicate" }, "keys": "ctrl+alt+t" } ] ``` Both this and the snippet I have above are treated the same way. <hr> PS: markdown protip: you can use "code fences" to have multiple lines of code in your comments. By using something like: ``` This is code With multiple lines ``` You can get content that looks like ``` This is code With multiple lines ```
Author
Owner

@nurbles commented on GitHub (Mar 20, 2020):

Thanks for the info about the arrays, it makes lots more sense when the multiple keystroke concept is added. Add I had seen before was comments about defining keys and key-chords that (to me) seemed to imply that the chords might need an array.

I guess I don't know git markdown well enough for advance code blocks. I foolishly trusted the 'insert code' button on this form to allow that, but it only inserts a single pair of backticks with the cursor placed between them, I guess for inline code examples. I was fooled into thinking the tool I was given did what I needed. Silly me. (smile)

@nurbles commented on GitHub (Mar 20, 2020): Thanks for the info about the arrays, it makes lots more sense when the multiple keystroke concept is added. Add I had seen before was comments about defining keys and key-chords that (to me) seemed to imply that the chords might need an array. I guess I don't know git markdown well enough for advance code blocks. I foolishly trusted the 'insert code' button on this form to allow that, but it only inserts a single pair of backticks with the cursor placed between them, I guess for inline code examples. I was fooled into thinking the tool I was given did what I needed. Silly me. (smile)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#6969