Add schema for key binding file

[colin-grant-work]

What it does

Fixes #5290 by adding a schema for keybindings that is updated whenever commands are registered or unregistered. It also adds an annotation to our various existing schemas (workspace files, tasks, debug, preferences) indicating that those files should be allowed to have trailing commas and comments, since they are parsed using the JSONC parser rather than standard JSON.

How to test

1. Create and open a keymaps.json file either yourself or from the Keybindings Widget.
2. Try to create a new keybinding by creating an array at the top level (if it hasn't already been created) and then creating an object in the array.
3. Trigger auto-complete suggestions (ctrl + .).
4. Observe that four fields are suggested (command, key, when, args).
5. Select command
6. Trigger autocompletion again.
7. You should see a list of all the commands available to be bound.
8. If you write something other than one of the available commands, you shouldn't get an error.
9. If you otherwise deviate from the schema (top-level object, non-string value for any of the fields except args), you should get a warning of some kind.

---

1. Adding trailing commas or comments to a preference file should no longer trigger a warning in the editor.

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[vince-fugnitto]

@colin-grant-work I'm getting some odd behaviors, perhaps you can confirm:

1. I sometimes get preferences when triggering (this happened for me initially, and later on as well when a proper schema was used):

keybindings-prefs.mp4

2. The keybindings-widget does not seem to populate key which seems to be required by the schema (is it something we should update as part of the pr?):

[colin-grant-work]

@vince-fugnitto

1. I sometimes get preferences when triggering (this happened for me initially, and later on as well when a proper schema was used):

This is not great, but not the fault of this code. Those suggestions are coming from the 'any string' suggestion machinery, and that appears to be very difficult to deactivate (happy for any suggestions!). @kenneth-marut-work has had the same difficulty in the breakpoint widget, and we haven't yet found a way to stop those string completions from coming through.

2. The keybindings-widget does not seem to populate key which seems to be required by the schema (is it something we should update as part of the pr?):

There seem to be a number of differences between our keybinding machinery and VSCode's. Their filename is keybindings.json ours in keymaps.json, and apparently we use keybinding in place of VSCode's key. I will update the schema to accept our keys with a deprecation warning, and update the machinery to handle VSCode's, so that the key binding file can function in the same way as the other preference files: we can accept either VSCode's or ours, although in this case, it's only ever stored in user storage. Still better to let people C&P their VSCode config in, rather than making them reformat.

[vince-fugnitto]

Those suggestions are coming from the 'any string' suggestion machinery, and that appears to be very difficult to deactivate (happy for any suggestions!)

I'm fine with the behavior we have for the moment, just wanted to point it out in case it was actually a bug with the pr, thank you for clarifying!

2. The keybindings-widget does not seem to populate key which seems to be required by the schema (is it something we should update as part of the pr?):

There seem to be a number of differences between our keybinding machinery and VSCode's. Their filename is keybindings.json ours in keymaps.json, and apparently we use keybinding in place of VSCode's key.

The filename difference is likely not so critical, the file is located in the user's home and we would not read .vscode/keybindings.json (or wherever it is located) in any case.

I will update the schema to accept our keys with a deprecation warning, and update the machinery to handle VSCode's, so that the key binding file can function in the same way as the other preference files

Sounds good to me!

[vince-fugnitto]

I can confirm that the recent changes work well 👍

I have a question, when we edit the keybinding for a command that has a context (deprecated in favor of when), we set context correctly in the keymaps.json. The issue is that hovering over context does not yield any information:

For example:

[
    {
        "command": "workbench.action.debug.pause",
        "keybinding": "ctrl+e",
        "context": "inDebugMode"
    },
    {
        "command": "-workbench.action.debug.pause",
        "keybinding": "f6",
        "context": "inDebugMode",
    },
]

context.mp4

[colin-grant-work]

@vince-fugnitto, I've added the context field to the schema with a deprecation warning. That means that it is omitted from auto-complete suggestions, but if it's present, it will be validated, a description will be available, and a deprecation warning will be shown.

[vince-fugnitto]

The changes work well for me 👍

I confirmed that:

• the keymaps.json now has a schema
• comments and trailing commas are permitted, and do not produce markers
• the schema has auto-completion, and intelligence (hovering) correctly
• the deprecated context is supported, and does not show up in the auto-completion