How to disable Fzf contrib autoloading

[stablestud]

Hi @akinomyoga,

I use the dotfiles managing tool chezmoi, which I setup to install fzf and its bash completion files from the fzf upstream to:

.local/bin/fzf
.bashrc.d/80-fzf_completion.bash
.bashrc.d/80-fzf_key_bindings.bash

In my .bashrc I source all .bashrc.d/*.bash files, therefore also loading the fzf files. As you can see, those are not standard locations, and ble.sh fails to find those and therefore it prints (kinda annoying) error messages.

Is there a way to disable autoloading the fzf integrations in ble.sh? Or even better, is there a way to specify the those files as a bleopt? Is there any benefit by letting ble.sh know where the fzf integrations files are? What are the benefits over loading them manually like I did?

Thank you in advance! :slightly_smiling_face:

[stablestud]

@dylankb maybe you know something about this? I added you since you helped to implement the FZF integration :slightly_smiling_face:

[akinomyoga]

Is there a way to disable autoloading the fzf integrations in ble.sh?

No, or exactly speaking, disabling the integration will make the fzf completion block the entire shell session and the shell does not respond anymore. The integration is needed to make the fzf completion work with ble.sh. This is related to the assumption that the fzf completion makes. Since ble.sh extends the completion feature of the shell, the behavior is inevitably not the same as the original Bash. For this reason, some subtle assumptions that the fzf completion uses to hack Bash is not satisfied with ble.sh.

Or even better, is there a way to specify the those files as a bleopt?

That is one possible solution.

Is there any benefit by letting ble.sh know where the fzf integrations files are?

Originally, we intended that the fzf completion and key-bindings are loaded through the fzf integration and didn't assume the case where the user loads those settings manually. This is because the adjustments of the fzf settings are always needed. The fzf-initialize module is designed for this situation to automatically detect the locations of the fzf settings that the user tries to load.

However, there are still users who try to load the fzf settings manually. For such a case, the core-complete module of ble.sh tries to automatically fix the problem when it detects a manually loaded fzf-completion setting. This is now done by afterward calling the module designed for the first way (indirectly loading the fzf settings through the integration).

The problem would be that the module designed for the first case (indirect loading) is just re-used for the second (unexpected) case (manual loading). In your situation, you would like to load the setting manually, which falls in the second case where ble.sh didn't assume.

What are the benefits over loading them manually like I did?

Because ble.sh needs to modify the settings that the fzf completion and key-binding set up. The most natural way is to intercept the loading stage of those fzf settings.

---

To determine a solution, I need to know the detailed setup of chezmoi or your specific setup. Depending on the actual situation, possible solutions are as follows:

• If you customize the settings that are defined in the default fzf completion or key-binding, you will probably need to write your own integration to make your fzf settings work with ble.sh. In that case, contrib/integration/fzf-{completion,key-binding}.bash will not be able to directly use but can be example implementations you can reference when you write your own integration.
• If you just copy/move the fzf settings to the specific directly ~/.bashrc.d, isn't it possible to keep the location of those files in the default locations somewhere under ~/.local/share/fzf/... and instead put ble-import lines in ~/.bashrc.d/80-fzf*.bash? That might not work because I'm not familiar with the chezmoi framework, but it would be the best solution if it works. If it doesn't work, could you explain how chezmoi works and the reason that it is not possible to keep the standard locations of the original files and put symlinks or source <standard locations> at 80-fzf*.bash.
• If those files are still kept somewhere inside ~/.local, I may add more "standard locations" to the list, though I'm not sure if it is actually the case. What is the result of the following command?

$ (cd ~; find .local | grep fzf)

The above solutions still try to load the fzf settings indirectly, but if you still need to do the manual sourcing of the fzf settings, I might think of separating the fzf integration module into the ones for two cases, i.e., for the auto-loading case and for the case of manual loading + afterward modification.

[akinomyoga]

I've created a user in a virtual machine with Ubuntu 20.04 LTS and installed chezmoi. I tried to find how chezmoi sets up fzf, but chezmoi doesn't seem to specify how fzf is installed. I guess the above setup of .local/bin/fzf, .bashrc.d/80-fzf_completion.bash, and .bashrc.d/80-fzf_key_bindings.bash is designed by you. Is my understanding correct? If there is a way to reproduce the provided setup using the chezmoi framework, could you describe it?

[akinomyoga]

@stablestud Could you provide the result of the following command?

$ (cd ~; find .local | grep fzf)

[stablestud]

Thanks @akinomyoga for the thorough explanation about the fzf integration. I thought the ble.sh implementation replaces the default fzf scripts, thus my confusion, but good to know, I will then but the fzf scripts into the default directory ~/.local/share/fzf/... and make us of ble-import.

And yes I manually setup chezmoi to put the fzf files into these destinations. For reference, here is my install instruction for fzf which will be executed by chezmoi: https://github.com/stablestud/dotfiles/blob/master/.chezmoiexternals/fzf.toml.tmpl

And here's the requested output:

.local/share/blesh/contrib/fzf-key-bindings.bash
.local/share/blesh/contrib/fzf-git.bash
.local/share/blesh/contrib/fzf-initialize.bash
.local/share/blesh/contrib/integration/fzf-key-bindings.bash
.local/share/blesh/contrib/integration/fzf-git.bash
.local/share/blesh/contrib/integration/fzf-initialize.bash
.local/share/blesh/contrib/integration/fzf-completion.bash
.local/share/blesh/contrib/fzf-completion.bash
.local/share/chezmoi/private_dot_config/fish/conf.d/99-fzf.fish
.local/share/chezmoi/.chezmoiexternals/fzf.toml.tmpl
.local/man/man1/fzf.1
.local/man/man1/fzf-tmux.1
.local/bin/fzf-tmux
.local/bin/fzf

[stablestud]

Looking at the integration scripts, I see that there is also one available for Zoxide.

Unfortunately the documentation for it is sparse and I wonder if there is any benefit of loading ble.sh zoxide integration? Currently I load Zoxides completion in ~/.bashrc.d/80-zoxide.bash with eval "$(zoxide init --cmd=j bash)" Should I also make use of ble.sh's zoxide integration?

[akinomyoga]

Thank you for your reply. Yes, the latest update of your configuration https://github.com/stablestud/dotfiles/commit/eca2fda936cae3457e6885f6f7bdc490f955f0fc is what I expect.

For the zoxide integration, you do not have to use it explicitly. You can just do eval "$(zoxide init --cmd=j bash)". ble.sh automatically loads contrib/integration/zoxide when it detects the zoxide configuration. The difference between the fzf settings (specifically the fzf key-bindings) and the zoxide completion is that the former needs modification at the loading time, but the latter can be modified afterward.

[stablestud]

Thank you! 😎 My issues are resolved 😄