Bug#1013356: fzf: Bash completions not active by default

[Matthijs Kooijman]

Package: fzf
Version: 0.30.0-1+b1
Severity: normal

Hi,

README.Debian says:

Note, since fzf 0.29.0-1, the bash completion is installed for bash by
default. Feel free to ignore the following instruction for fzf >=
0.29.0-1.

It seems this means that the completion is installed as
/usr/share/bash-completion/completions/fzf

However, completions from that directory are not loaded by default, but
are loaded dynamically when the user tries to complete arguments to
their command.

See e.g.:

https://salsa.debian.org/debian/bash-completion/-/blob/master/bash_completion#L2175

In practice, this means that in a new shell, doing "cd **<tab>" does not
offer completion. If I then do "fzf <tab>", the completion is loaded,
and after that "cd **<tab>" *does* offer fzf completion.

This was tested on Ubuntu 22.04, but with the sid version of fzf
(0.30.0-1+b1) and bash-completion (2:2.11-6), so I'm assuming the same
behavior happens on Debian.


I'm not sure if there is a way for the package to bypass this dynamic
loading and have a snippet be loaded automatically (other than putting
a file in `/etc/bash_completion.d`, but that seems to be for
compatibility only).

What does seem to work is to load it explicitly in `~/.bashrc`:

source /usr/share/bash-completion/completions/fzf

So maybe that chould be documented?

Gr.

Matthijs

-- System Information:
Debian Release: bookworm/sid
APT prefers jammy-updates
APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), (100, 'jammy-backports'), (50, 'unstable-debug'), (50, 'testing-debug'), (50, 'stable-security'), (50, 'stable-debug'), (50, 'unstable'), (50, 'testing'), (50, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-25-generic (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

[Bastian Venthur]

Package: fzf
Version: 0.35.1-1
Followup-For: Bug #1013356
X-Debbugs-Cc: ven...@debian.org

I can confirm that this issue still exists, bash completion is only available
after you did:

fzf <TAB>


Cheers,

Bastian

-- System Information:
Debian Release: bookworm/sid

APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set

[sodaqx+9gf...@cs.email]

Package: fzf
Version: 0.38.0-1+b1
Followup-For: Bug #1013356

Dear Maintainer,

I confirm that this issue exists in fzf in the version released in Debian 12 (bookworm) stable.

The only thing that needs changing is documenting the workaround in the /usr/share/doc/fzf/README.Debian so that people know they have to source the bash completions file manually in their bashrc

[Bastian Venthur]

Package: fzf
Version: 0.42.0-1+b2

Followup-For: Bug #1013356
X-Debbugs-Cc: ven...@debian.org

Hi,

i can confirm this issue. I wonder is there a reason why the bash completion is
not enabled by default? Other packages provide their bash completions by
default as well and it is certainly the behaviour I'd expect when installing
fzf.


Cheers,

Bastian

-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN

Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fzf depends on:
ii libc6 2.37-10

fzf recommends no packages.

fzf suggests no packages.

-- no debconf information

[Christoph Anton Mitterer]

Hey.

A workaround would be what the git package does with:
/etc/bash_completion.d/git-prompt
which sources:
/usr/lib/git-core/git-sh-prompt
which in turn provides:
__git_ps1()
and some others that are thereby unconditionally loaded by every bash
instance.

I've asked upstream whether there are means to have files in /usr/
sourced unconditionally, perhaps that would be a better approach - at
least if there'd be also a way to mask that again:
https://github.com/scop/bash-completion/issues/1055


Cheers,
Chris.

[Christoph Anton Mitterer]

Just for the records:

The workaround I've proposed before (using something like
/etc/bash_completion.d/fzf) may not be the best way either.

I'm looking into what should be done (see also discussion
at https://github.com/scop/bash-completion/issues/1055), but perhaps
the ideal solution would first require some fzf upstream changes.


Cheers,
Chris.

[Christoph Anton Mitterer]

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.

[Bastian Venthur]

Package: fzf
Version: 0.42.0-1+b3

Followup-For: Bug #1013356
X-Debbugs-Cc: ven...@debian.org

Dear Maintainer,

there's also this weird behaviour, that wile bash completion is not enabled by
default, it will be enabled once you do:

fzf **<TAB>

after that a

cd **<TAB>

works as expected. If bash completion is not enabled on purpose, I would
consider this behaviou a bug. But I believe just enabling the bash completion
by default would be the better solution.


Cheers,

Bastian



-- System Information:

Debian Release: trixie/sid
APT prefers unstable

APT policy: (500, 'unstable')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)

Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fzf depends on:

ii libc6 2.37-12

[Christoph Anton Mitterer]

On Fri, 2023-11-17 at 08:40 +0100, Bastian Venthur wrote:
> If bash completion is not enabled on purpose, I would
> consider this behaviou a bug. But I believe just enabling the bash
> completion
> by default would be the better solution.

In any case, please do not enable the fzf-completion (i.e. **<TAB>) by
default, unless there's an easy way to manually disable that (which is
not easy if the file is installed to /usr/share/bash-
completion/completions/fzf )

The problem with fzf’s completion file is, that it contains both:
1. the completion for the fzf program itself
2. the "generic" (well only to some very limited amount) **<TAB>
completion

The latter is unfortunately rather limited and even buggy in many
cases.
I tried to get that improved, but upstream eventually decided that he
doesn't want the functionality to be expanded/fixed.

Alternative integrations exist, but these do not work properly when
fzf’s own is also enabled.


Therefore, please stop installing the completion file to:
/usr/share/bash-completion/completions/fzf

This is anyway not an appropriate location, as neither of the two
completions mentioned above actually use bash-completion.

IMO the proper way would be:
- users need to manually source (2) (or manually install it in
/etc/profile.d or the likes)
- the parts for (1) should be split of into a separate file and that
could actually be installed into
 /usr/share/bash-completion/completions/
(not because it would really use anything of bash-completion, but
only to get the opportunistic loading of that)

I've had talked to upstream about splitting the two
(https://github.com/junegunn/fzf/issues/3457), but again... he does not
seem to have much interest in improving things.

If you really need to have fzf's completion file automatically loaded,
please add some easy way to disable that. Otherwise you break the setup
of people who want to use better alternative integrations.

Cheers,
Chris.