should completion.* be split up?

[calestyo]

• I have read through the manual page (man fzf)
• I have the latest version of fzf
• I have searched through the existing issues

Info

• OS
  • Linux
  • Mac OS X
  • Windows
  • Etc.
• Shell
  • bash
  • zsh
  • fish

Problem / Steps to reproduce

I wonder whether the completion.* should/could be split up, at least in the bash case.

Some background:

I've stumbled over Debian bug #1013356, where the problem is that fzf’s shell function for **<TAB> completion aren’t loaded properly.

The reason is that completion.bash is installed into /usr/share/bash-completion/completions/fzf, which is then however only loaded on-demand (per shell session), which bash-completion only does, when completing fzf like in:

$ fzf <TAB>

Also, AFAIU, the completion.* ship currently code for two kinds of completions:
a. completing options for fzf itself (e.g. fzf --height)
b. completing other stuff (e.g. hostnames in ssh **<TAB>, etc.)
And AFAIU, there's no dependency on bash-completion.

Without any bigger changes to infrastructure (on the distro side), I'd see basically the following solutions for the Debian issue:

1. don't install the file at all, but keep it e.g. as /usr/share/fzf/shell/completion.bash (I, personally don't like if Debian would place it as /usr/share/doc/fzf/examples/completion.*, which it does right now for the other shell scripts from fzf)
2. install it into /etc/profile.d/
3. install it into /etc/bash_completion.d/
4. install it into /etc/bash.bashrc.d or something like that

(1) has the disadvantage that fzf’s completions (both, (a) and (b)) wouldn't work out of the box anymore. But has the advantage hat a (non-root) user can easily disable them (by not manually sourcing them) and easily use e.g. alternative solutions like lincheney/fzf-tab-completion.

(2) Would require an additional check in all the files, whether the right shell (e.g. bash or zsh) is active. The check for interactiveness alone wouldn't suffice. Also, it’s (at least in Debian) again not easily possible for a (non-root) user to disable loading of them.

(3) Would require no additional checks like in (2). But it's only somewhat easy for a (non-root) user to disable loading it (IIRC one could set BASH_COMPLETION_COMPAT_DIR or so - but via that, only disable loading all files in /etc/bash_completion.d/, not just e.g. fzf).

(4) At least in Debian, a counterpart mechanism to /etc/profile.d/ - but just for bashrc doesn’t even exist.

All these would in principle be on the distro side, but there's one thing that might be done on the fzf side:

If a distro does any of the above both, (a) and (b) (and the functions for those), will always be loaded, right?

For (b) there's no real way around that, but for (a) (i.e. the completion of fzf itselef) this shouldn't be necessary. It would be nice, if for that the on-demand loading provided by bash-completion’s /usr/share/bash-completion/completions/fzf could be used, so that _fzf_opts_completion would only be loaded, if someone actually tries to complete fzf (itself).

For (a), there are probably also no alternative implementations, so there's no real need for a (non-root) user to be able to disable loading the completions for that.

So long story short, what would you think about splitting up completion.bash?

This could also have more benefits than just keeping the shell environment a bit smaller when fzf itself is not completed:

As completion.* grow, it might make sense to split things up anyway (similar as bash-completion is split up):

• A generic part, that provides functions like __fzf_list_hosts(), _fzf_host_completion(), __fzf_defc() and _fzf_setup_completion(), etc.
• More specific parts, like for SSH with _fzf_complete_ssh(), which then also set up the actual completion (via the generic __fzf_defc() and _fzf_setup_completion()). This could also make it easier for users to selectively not load fzf-completions for certain programs.

Cheers,
Chris.

[calestyo]

Along such change, if accepted, one could perhaps re-organise the shell/ dir in git a bit, perhaps like so:

shell/
├── bash
│   ├── bash-completion
│   │   └── fzf             <- would be the code for completing fzf itself (despite not strictly using bash-completion)
│   ├── fzf-completion
│   │   ├── completions     <- specific completions using fzf, those shipped by fzf itself, but 3rd party ones could also end up in the installed dir of that
│   │   │   ├── git
│   │   │   └── ssh
│   │   └── fzf_completions <- all the generic stuff __fzf_list_hosts(), etc.
│   └── key-bindings.sh
├── fish
└── zsh

These could then be installed like so:

• shell/bash/bash-completion/fzf -> /usr/share/bash-completion/completions/fzf (if the on-demand loading of bash-completion shall be used)
• shell/bash/key-bindings.sh into /usr/share/fzf/key-bindings.sh
• shell/bash/fzf-completion/ into /usr/share/fzf/fzf-completion/
  Where 3rd party projects would also place their scripts in /usr/share/fzf/fzf-completion/completions/.
  One would need to think of some way how people should source that... ideally only one file (e.g. fzf_completions) and that sources all the ones in the subdir... but also somehow providing a way, to selectively disable or enable those from subdirs.

[junegunn]

The completion for fzf itself hasn't been maintained for years, so it's missing a lot of new options, I'm planning to remove it completely as I don't see myself working on it in the near future.

• split up "normal completion" and "fuzzy completion integration" #3033
• [feature] shell completion #2808

Even if I decide to provide completion for fzf itself, I'll probably take a different approach to support not only bash but also zsh and fish using something like https://github.com/spf13/cobra/

[calestyo]

Hmm, that would be a pity. One should then rather try to get it into bash-completion? At least to have something that works until any other approach would be working.