Hey folks. I filed an issue upstream at: https://github.com/junegunn/fzf/issues/3457
which describes the situation leading to this bug and discusses possible solutions. The main problem is IMO, that right now, fzf's completion.bash file contains both, code for: a. completing options for fzf itself (e.g. fzf --height) b. completing other stuff (e.g. hostnames in ssh **<TAB>, etc.) While the code from (a) doen't strictly depend on bash-completion (but only the completion functionality of bash), I'd still say there is some benefit for that to go into: /usr/share/bash-completion/completions/fzf namely, the on-demand loading, that means that the completion functions for fzf *itself* are only loaded if necessary. Howver, (b) MUST NOT go into /usr/share/bash-completion/completions/fzf for at least two reasons: - It doesn't work (as reported in this Debian bug), because the functions are there only loaded by bash-completion, if fzf *itself* is completed. - There is not easy/good way for (non-root) users to disable the (b)-part, from there. This (being able to disable it) is however likely necessary, if a user wants to 1) simply not use the functionality at all or 2) use an alternative implementation for it, like e.g.: https://github.com/lincheney/fzf-tab-completion or https://github.com/rockandska/fzf-obc How to move forward? First we should wait what upstream thinks about https://github.com/junegunn/fzf/issues/3457 . There I propose the current completion.bash file to be split up in the two functionalities described above, (a) and (b). If upstream would agree, we should ship the file for the (a) part as: /usr/share/bash-completion/completions/fzf in order to utilise bash-completions on-demand loading For the (b) part I'd say we should do the following: - ship the file itself as some /usr/share/fzf<whatever> then either: - leave it at the users to source that file in their .bashrc or so or: - somehow source it out-of-the-box in either /etc/profile.d/[0] or /etc/bash_completion.d/ Either as symlink, or via some wrapper script. The latter could provide some easy way for the user to disable loading of the script (on a per-user basis) If upstream would *not* want to split up the file, I'd say we do the same than above, except that we cannot ship *anything* in /usr/share/bash-completion/completions/ . Thus, even the completion for fzf *itself* would need to be loaded via the ways described above for the (b) part. Of course Debian could on its own split up the file... but I guess that would add quite some ugly maintenance burden no one wants. Thanks, Chris. [0] Would require an additional test, whether the shell is really bash.
