Option to set fzf binary

[wshanks]

I have a problem using fzf-tmux with xonsh. I am not actually sure what the problem is but when I call fzf-tmux inside of a tmux session started from xonsh a window opens, some kind of traceback appears, and then the window disappears before I can read it. I had never tried to use fzf-tmux before using this xontrib, so this problem had never bothered me. With the published xontrib, the key bindings don't work inside of tmux for me because they try to use the problematic fzf-tmux. #1 fixes the problem for me but only because it introduced a bug that prevents fzf-tmux from ever being used. This line:

xontrib-fzf-widgets/xontrib/fzf-widgets.xsh

Line 12 in 62aacd7

if 'TMUX' in ${...} and $(which fzf_tmux_cmd):

should really be:

    if 'TMUX' in ${...} and $(which @(fzf_tmux_cmd)):

What would your preference be for addressing this? I can think of three options:

1. Remove all support for fzf-tmux. Just use fzf.
2. Replace fzf-tmux support with a $fzf_bin variable that when set is used instead of fzf (then the user could choose between fzf and fzf-tmux in .xonshrc).
3. Retain fzf-tmux support but also implement the $fzf_bin variable which would override it.

What I hope you don't choose is just to implement the @(...) fix I described above because that will lead to the xontrib always using (the broken, for me) fzf-tmux instead of fzf inside of tmux.

[laloch]

@willsALMANJ, thanks for reporting. I'll try to investigate what the problem with fzf-tmux is first.

[laloch]

See junegunn/fzf#2166. Do you still think we need a fix other than $(which @(fzf_tmux_cmd))?

[brechtm]

Note that when fzf_tmux_cmd is not available, this xontrib will output the following on every fzf call:

fzf_tmux_cmd not in $PATH or xonsh.builtins.aliases

This can be fixed by suppressing the which output in fzf-widgets.sh:

    if 'TMUX' in ${...} and $(which @(fzf_tmux_cmd) err>/dev/null):