Specify a file for settings instead of just allowing editing in settings.json directly?

[macintacos]

I'm working on adding a lot of chord to my keymap set for VSpaceCode (which I definitely plan on sharing when I'm done). I'm just about halfway done, and one thing that I've already noticed is that my settings.json file is enormous now. For context, I've added about 40 or so menu items, which has resulted in roughly 450 new lines in my settings.json file.

As you can imagine, this is making my settings.json file a bit unwieldy at this point. I think it'd be a lot cleaner if I could just specify a variable like vspacecode.bindingOverridesFile and specify the full path to that file, and then vscode-which-key just expands that.

[stevenguh]

That's interested idea!

Again, I am just dumping my brain here. Here are a few things I am thinking

1. Using settings.json to store bindings allows people to sync settings across machines/Codespaces with the upcoming Settings Sync, file url might not work across machines.
2. This work needs think about how other extension like VSpaceCode can pass file url to this extension as they maintain different variables for their menus.
3. The extension current track changes made to settings.json and update accordingly with vscode's API. Using file url might mean that we need to track file changes or may require a reload of the instance when the file is changed for it to be effective.
4. File url variable is probably not going to work with Codespaces
5. The file url variable is probably complimenting whichkey.bindings, which allows user to completely change the binding from scratch.
6. Despite all that, I am still feel positive about this because it's a bit like how vscode vim can read .vimrc

[macintacos]

Speaking personally of course, I don't particularly care about syncing or codespaces. I have only one machine I care about, although I totally get your point; just wouldn't be applicable to me. Completely understand that you wouldn't want to implement this without thinking about those aspects though.

As long as we're just spitting out ideas, one thing that could be interesting is just specifying a glob pattern and also accepting arbitrary URLs, similar to how the VSCode YAML extension does it (check out the "Associating a schema to a glob pattern via yaml.schemas" section in their README here to understand what I mean). Even if you could just specify regex, regex could handle a schema file being in multiple places at once, and could also allow you to split out configurations across multiple files. Implementing that could also potentially handle specifying certain keybindings only when a certain file type is active, which I mean to me is just 🤯.

Although obviously that'd probably complicate the code in this project quite a bit, it's interesting to at least theorize about.

[The-Compiler]

I've been thinking about this for a bit, and I wonder if it would be possible (and if so, a good idea) to allow settings extensions to contribute bindings?

That'd mean:

• "Layers" (or major mode configurations) could potentially be maintained independently from VSpaceCode itself (probably more of a nuisance right now, but if VSpaceCode ever gets as popular as spacemacs with ~7000 PRs, probably needed at some point?)
• Other VS Code extensions could possibly bundle VSpaceCode support for their bindings
• Users could build an extension for their custom bindings (which, hopefully, shouldn't be too hard?) which keeps them separate from the settings file, but still easily syncable across machines

[stevenguh]

@The-Compiler This seems to relate to the Layer issue. I replied some of my thoughts at VSpaceCode/VSpaceCode#199 (comment)