Keymap Context Alias & Nested Contexts #20481
Labels
admin read
Pending admin review
enhancement
[core label]
triage
Maintainer needs to classify the issue
Check for existing issues
Describe the feature
My keymap has gotten kind of complex and it can be tiring and verbose to specify new contexts where only one thing changes. For example I use vim mode which adds a lot of context management overhead, and often times I want to bind a key to a different task depending on the filetype.
as you can see there is a lot of cognitive overhead in simply changing one parameter for the context, namely && extension == kt. When I want to place a keymap I generally just want to place it in somewhere that makes sense, and parsing out a long boolean expression looking for small differences between each long expression can end up taking quite a bit of time.
I see two (possibly complementary) solutions.
The first (most backward compatible one) would be to allow context aliases. See this for example:
Old config
Config with context aliases
The new version is a lot easier to parse and find where I need to put a keymap quickly. It also just allows for a lot more customization without affecting people's existing configs, since its just an optional additional field to specify the aliases.
Another solution would be to allow nesting contexts, in a tree structure that allow you to put more generic keybindings at the top of the tree and contexts that add on to the parent context limiting it by just one more expression. That way we could have the afformentioned $ed_nv context, then under that context add another one for $kt and $gleam specific bindings that add on to the parent context.
The text was updated successfully, but these errors were encountered: