v7.0

[PatrickF1]

I am so proud of this release. fzf.fish is now in a state that I am very content with. Users should have a very seamless experience using it, and developers will have fewer hurdles to overcome to add new features. Unfortunately, and as should be expected for such an improvement, this does mean some migration work for everyone; make sure to read the migration notes at the bottom.

Custom key bindings elevated to be a first-class feature (#172)

Background and motivation

fzf.fish ships with default key bindings that are mnemonic and have minimal conflicts with existing fish key bindings. However, for users who want to change them, the process of customizing them is frustrating and confusing at best. This frustration has culminated in a steady stream of issues, discussions, PRs, and Wiki sections around key bindings (#17, #89, #99, #108, #103, #153, #162, Wiki section). Here are the shortcomings of making custom bindings DIY:

• Besides not installing the default bindings if fzf_fish_custom_keybindings is set, the plugin provides zero assistance to the user when it comes to installing the custom bindings. Users have to study config/fzf.fish, bind documentation, and maybe even even some basic fish syntax for advanced cases. This is too daunting. Furthermore, users have to reference functions clearly denoted private (__fzf_search_*)., which feels and is hacky. Ideally, the plugin does not require typical users to dive into its code and will abstract private functions away completely.
• fzf_fish_custom_keybindings is all or nothing; users have to opt out of ALL default key bindings and re-bind them themselves even if they only want to change one. This is tedious, verbose, and unwieldy. A good plugin should allow tweaking the key binding while maintaining the rest of the defaults.
• Because the fzf_fish_custom_keybindings has to be set before config/fzf.fish is executed, it has to be created as a universal variable. Unfortunately, universal variables are a very confusing point for new fish users.
• And because it needs to be universal, it's bad practice to add it to one's config.fish. This makes it more difficult for one's fzf.fish configuration to be checked into git.

As the plugin author, I have also felt the pain of working around this DIY custom binding mechanism:

• Because custom bindings are so painful to use, user forego custom bindings and get stuck with the defaults, which puts a lot of pressure on me (subconsciously and through the many issues opened) to make the default bindings suitable for everyone. Unfortunately, the goal of having a default set of key bindings that is suitable for even 80% of users while being easy to learn (or mnemonic) is nigh impossible, requiring a thorough understanding of the multitudes of CLIs and terminals people use, the ways they use them, and they key binding. I've concluded this task is ultimately futile because key bindings are very idiosyncratic. Therefore, custom key bindings should be a first class feature that is well supported, completely documented, flexible, painless to use, and directly encouraged.
• Any change, even an addition (such as a new feature), to the default key bindings is an monumental event because it's not transparent and hard to communicate to users. In fisher, there isn't a mechanism for precisely warning users of backwards incompatible changes. Furthermore, the only place where the default key bindings are officially listed is on the readme. The best I can do is to cut a new major release and post on Reddit and Gitter to announce any and all key binding changes. But still, most users will probably be left in the dark when their key bindings silently break on the next update. If more users customized their key bindings and (which they don't because again, it's not well supported) and there was an interface to quickly view the default key bindings, this would be a much smaller problem.
• Because users have to hardcode in the function names for their custom key bindings, fzf.fish's internal functions are not really private and I cannot rename them as they morph. This is important to me as the names of some features, and therefore the ideal function name, have shifted since their inception.
• Finally, fzf_fish_custom_keybindings has an annoying typo: key binding is two words, not one.

TL;DR The new solution

A new function called fzf_configure_bindings solves or mitigates all of the aforementioned problems. It:

• serves as a wrapper around the key bindings and fzf.fish's private functions so that they are properly abstracted away under a lightweight interface.
• allows customizing the key binding for each feature through namesake options (e.g. --directory controls the search directory key binding). Bindings can be overridden or, if the user doesn't want to use the feature, even disabled.
• uses mnemonic key sequences by default for features that the user chooses to not customize. This means that to change the key bind for a single feature, only one option needs to be specified.
• comes with great, easy-to-read help documentation that prints if used incorrectly.
• includes the default key bindings in its help message so users can easily and quickly find them.
• is robust and thoroughly tested.
• will include command completion (to be implemented later).

IMPORTANT: Migration required

Everyone has to do some migration work. This is because I took the opportunity of this major release to make two backwards incompatible changes I've been waiting to do and that are now optimal given the ease of using fzf_configure_bindings.

• search directory's key binding has changed to Ctrl+Alt+F (98c3a47)
• all fzf's private functions have been renamed, so users who were binding it themselves must switch to fzf_configure_bindings (a7b9608, ed97b9e)

Hopefully, the migration process is not too painful and worth it. Check the migration guide for tips

---

This discussion was created from the release v7.0.