Comments (8)
stevenguh
commented on July 3, 2024
On the last point of inheritance, we might able to do something like
[
{
"key": "languageId:c",
"name": "+Buffers/Editors",
"type": "bindings",
"bindings": "vspacecode.bindingRef.c"
},
{
"key": "languageId:cpp",
"name": "+Buffers/Editors",
"type": "bindings",
"bindings": {
"ref": "vspacecode.bindingRef.c",
"overrides": "vspacecode.overridesRef.cpp"
}
}
]from vscode-which-key.
MarcoIeni
commented on July 3, 2024
Instead of inheritance, we could use composition, i.e. we have some group of bindings called "shared c/c++" and both c and c++ include those bindings.
This could be useful because we could share all the common bindings across all major modes
from vscode-which-key.
stevenguh
commented on July 3, 2024
I think I understand mostly what you are saying, but to drive it home. Can you provide an example of the "composition"?
from vscode-which-key.
MarcoIeni
commented on July 3, 2024
Something like this:
{
"vspacecode.bindings": {
"type": "array",
"markdownDescription": "The bindings of the which key menu",
"lsp": [
{
"key": "=",
"name": "+Format",
"type": "bindings",
"bindings": [
{
"key": "=",
"name": "Format region or buffer",
"type": "command",
"command": "editor.action.format"
}
]
}
],
"default": [
{
"key": "languageId:rust",
"name": "Rust",
"type": "bindings",
"common_bindings": ["lsp"],
"bindings": [
{
"key": "T",
"name": "Toggle inlay hints",
"type": "command",
"command": "rust-analyzer.toggleInlayHints"
}
]
},
{
"key": "languageId:c",
"name": "C",
"type": "bindings",
"common_bindings": ["lsp"],
"bindings": [
{
"key": "X",
"name": "Do amazing c Stuff",
"type": "command",
"command": "c-analyzer.command"
}
]
}
]
}
}This is just a sketch to give you the idea, do not take into consideration field names and syntax :)
In this way both rust and c have the common "lsp" bindings. And we could stop copy pasting those everywhere.
At the same time you could have "common-js" for js/ts or "common-c" for c/cpp similarly to how I defined "lsp".
So for example c would have "common_bindings": ["lsp", "common-c"]
from vscode-which-key.
stevenguh
commented on July 3, 2024
Thank you for the example. It still feels a little bit like an inheritance and can have conflicting bindings where two common binding ref might have conflicting bindings.
To keep it simple, we can offer a simple binding reference like
[
{
"key": "languageId:c",
"name": "+Buffers/Editors",
"type": "bindings",
"bindings": "vspacecode.bindingRef.c"
},
]so we don't have duplicate bindings for c/c++ and js/ts.
In addition, we can just use strict composition, for some case it may still be tedious to declare not exact duplicate bindings but at least it is clear.
[
{
"key": "languageId:c",
"name": "+Buffers/Editors",
"type": "bindings",
"bindings": [
{
"key": "g",
"name": "+Go to",
"type": "bindings",
"bindings": "vspacecode.lsp.goto"
}
// ...
]
},
]Also, I am thinking the thinking in implementation of layers might change how this should be implemented. See VSpaceCode/VSpaceCode#199
from vscode-which-key.
MarcoIeni
commented on July 3, 2024
sorry but it's not very clear to me. Maybe it would be helpful if you reproduce my example with your syntax, if you don't mind.
from vscode-which-key.
stevenguh
commented on July 3, 2024
{
"vspacecode.bindings": {
"type": "array",
"markdownDescription": "The bindings of the which key menu",
"lsp": [
{
"key": "=",
"name": "+Format",
"type": "bindings",
"bindings": [
{
"key": "=",
"name": "Format region or buffer",
"type": "command",
"command": "editor.action.format"
}
]
}
],
"lsp2": [
{
"key": "=",
"name": "+Format",
"type": "command",
"bindings": [
{
"key": "=",
"name": "do something else",
"type": "command",
"command": "do.something.else"
},
{
"key": "x",
"name": "do something else2",
"type": "command",
"command": "do.something.else2"
}
]
}
],
"default": [
{
"key": "languageId:rust",
"name": "Rust",
"type": "bindings",
"common_bindings": ["lsp", "lsp2"],
"bindings": [
{
"key": "T",
"name": "Toggle inlay hints",
"type": "command",
"command": "rust-analyzer.toggleInlayHints"
}
]
}
]
}
}Thank you for bearing with me. For example, default will have two common bindings lsp and lsp2; however, lsp and lsp2 both defined = key. We will have conflict in this case, we will have figure out how to resolve them (e.g. subsequent common_bindings override or merging automatically). It reminds me of multiple inheritance problems, which can introduce a lot of complicity.
I was suggesting to start something simple which allows direct reference only like
{
"vspacecode.bindings": {
"type": "array",
"markdownDescription": "The bindings of the which key menu",
"lsp2": [
{
"key": "=",
"name": "do something else",
"type": "command",
"command": "do.something.else"
},
{
"key": "x",
"name": "do something else2",
"type": "command",
"command": "do.something.else2"
}
],
"default": [
{
"key": "languageId:rust",
"name": "Rust",
"type": "bindings",
"bindings": [
{
"key": "=",
"name": "+Format",
"type": "bindings",
"bindings": "vspacecode.bindings.lsp2"
}
{
"key": "T",
"name": "Toggle inlay hints",
"type": "command",
"command": "rust-analyzer.toggleInlayHints"
}
]
}
]
}
}However, it is quite inflexible as it requires a set of bindings to defined elsewhere. In addition, the implementation of layer will influence how we should declare bindings greatly.
from vscode-which-key.
MarcoIeni
commented on July 3, 2024
Oh, I see now, thanks a lot for bearing with me too!
Yes it looks good to me :D
from vscode-which-key.
Related Issues (20)
- Support partial override HOT 1
- triggerKey Not Firing from edamagit HOT 7
- Weird behaviour with Github Pull Request extension HOT 1
- `whichkey.delay` causes a delay in `SPC SPC` shortcut, others seem to be unaffected HOT 6
- Add default binding for `git pull`
- Crash when mixing `key` / `keys` and using `whichkey.sortOrder` HOT 2
- [bug/ feature?]: whichkey.searchBindings should support fuzzy search HOT 2
- [Help Wanted] Show the menu when press g HOT 3
- Debug Transient State gets closed. HOT 4
- Support several menus HOT 4
- Space keybind with vscode-neovim and the Commands option HOT 5
- `bindings` vs `bindingOverrides` and `keys` vs `key` HOT 3
- Ability to specify font for menu "keys" HOT 6
- Typos in commands
- Reliable key sequence handling HOT 2
- Is there a way to have bindings without a doc, and vice versa? HOT 1
- Support initial menu delay HOT 1
- Configure context menu delay? HOT 2
- Code get unselected when menu pops up HOT 1
- command not found HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vscode-which-key.