Fuzzy completion for custom commands is broken.

[gregorias]

• Category
  • fzf binary
  • fzf-tmux script
  • Key bindings
  • Completion
  • Vim
  • Neovim
  • Etc.
• OS
  • Linux
  • Mac OS X
  • Windows
  • Windows Subsystem for Linux
  • Etc.
• Shell
  • bash
  • zsh
  • fish

Steps to reproduce and behaviour

1. Run complete -F _fzf_path_completion -o default -o bashdefault fake_cmd
2. Type fake_cmd any_dir<TAB><TAB>

Now typing fake_cmd **<TAB><TAB> stops working and returns default tab completion.

Root cause

In step 2. the completion function for fake_cmd is changed to bash' default - _minimal.

Before step 2., complete | grep fake_cmd outputs complete -F _fzf_path_completion -o default -o bashdefault fake_cmd, but after step 2., the command outputs complete -F _minimal fake_cmd.

This change happens, when _completion_loader is run at:

fzf/shell/completion.bash

Line 125 in 9615c4e

_completion_loader "$@"

L125 affects all other commands, however the original completion function is restored later -

fzf/shell/completion.bash

Lines 127 to 128 in 9615c4e

	eval "$(complete | command grep "\-F.* $orig_cmd$" | _fzf_orig_completion_filter)"
	source "${BASH_SOURCE[0]}"

This restoration doesn't affect fake_cmd, because it is not in a_cmds:

fzf/shell/completion.bash

Line 265 in 9615c4e

a_cmds="

Note that this if the fake_cmd is inside /etc/bash_completion.d/, then _completion_loader doesn't fail, and the switch doesn't happen.

[junegunn]

Thanks for the detailed report. Let me see if I can find a way to fix it.

[gregorias]

I made a_cmds variable configurable in gregorias@3fc31ac and use it in my personal config: I presume that you might want something different for the wider audience.

[junegunn]

I believe 620f064 fixes the issue (it's not in the master branch).

[gregorias]

+1 I confirm that the current devel branch doesn't exhibit this bug. Thank you!

I wonder if it's reasonable to add a regression test for this bug.

[junegunn]

Yes, we should. I'm just putting if off because it's a tedious task and I don't have much time. Patches are welcome.

[gregorias]

Got it, I'll take a look today (CET time) to see if I can do it within a reasonable timeframe, but I don't expect much. The testing infrastructure is to me usually the second most arcane thing in projects; right behind the build infrastructure.

[junegunn]

No hurries, we can do it anytime. The testing code is actually a bit of a mess, we're using ruby code to control tmux windows and panes to test interactive test scenarios.

[jbriales]

I'm hitting an issue that exhibits the EXACT same behavior explained in the original post. Wasn't this fixed in master already by a previous commit?
I can provide more details if necessary to try and reproduce.