New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modularize user key bindings #5191
Comments
I've actually been thinking about doing away with the need for Really, the only reason that function is needed is because, when the user switches binding sets (e.g. from emacs to vi) we want to erase everything belonging to the old set. So what we do now is to erase everything and rerun that function. What I've been thinking about is to add a "--default" or "--system" switch to So what fisher/omf/fundle would then do is simply call |
@faho Do you mean that it would work similarly to So, with complete we can already |
Not really, no. Just if you call If you do I don't think we would need any special files to support this - you'd do |
Wouldn't that run into the same problem of using |
I haven't run any benchmarks, but I suspect this wouldn't be scalable as it would force every script that wants to add its own bindings to copy any existing echo "...initializing my script"
if functions -q fish_user_key_bindings
functions --copy fish_user_key_bindings _my_script_fish_user_key_bindings
end
function fish_user_key_bindings
bind ...
bind ...
bind ...
if functions -q _my_script_fish_user_key_bindings
_my_script_fish_user_key_bindings
end
end If I have 10 my_script-like files in A more sensible approach would be to copy the function only once and source a bunch of files with the Now, perhaps I still don't understand what "doing away with the need for That would be a breaking change, and IMO, a less optimal plan of action, as it would force plugin manager authors to go to great lengths if they intend to support at least fish >=2.3, as I intend to do. |
Correct.
What I mean, in short, is this: Making
Ever wondered why that is? It's because we only set up your bindings after config.fish has run (via a function triggered What I want is to erase all bindings that have been set up as part of a binding set (which won't include any bindings you've set up previously). Then we can still run Which means:
You wouldn't have to! You'd just do And also:
It wouldn't, because we'd still run [0]: Of course we could also stop erasing all bindings the first time the bindings are set up. That would make |
This allows for marking certain bindings as part of a preset, which allows us to - only erase those when switching presets - go back to the preset binding when erasing a user binding - only show user customization if requested - make bare bind statements in config.fish work (!!!11elf!!!) Fixes fish-shell#5191. Fixes fish-shell#3699.
Would you consider making fish aware of a new keybindings directory inside
$__fish_datadir
,XDG_CONFIG_HOME
, etc.?Then, during startup, copy the user's
fish_user_key_bindings
function (if there is one) and create a newfish_user_key_bindings
function that when invoked, will source every file in eachkeybindings/
directory in$__fish_datadir
andXDG_CONFIG_HOME
.Basically this:
I can emulate this behavior using
conf.d
and distribute that script as a package, but it would be nice to have this out of the box.In fisher v2.x (since I depend exclusively on fish autoloading feature) I go to great lengths to generate a
fish_user_key_bindings
function on the fly that concatenates the keybindings exported by each package with the user's key bindings defined inside theirfish_user_key_bindings
, but it's highly impractical (and buggy). In fisher v3.x I'll work around this more cleanly with a package as suggested above, but it would be nice if I didn't need to.Oh-my-fish (here) and fundle (here) emulate this behavior through the user's
config.fish
using the same (or similar) technique described above.The text was updated successfully, but these errors were encountered: