Should FZF have its own config file?

[j-xella]

My FZF_DEFAULT_OPTS variable is getting quite long and hairy, which got me thinking - is it the time for fzf to be able to read its configuration from a proper config file (~/.fzfrc, ~/.config/fzf/config or something similar ???)

[rayiik]

why dont you use one? all a config file is a file that gets sourced by the shell startup scripts (most of the time).

#!/bin/bash
        export FZF_MOVEMENT="--bind='ctrl-s:preview-page-down' \
          --bind='alt-p:toggle-preview' \
          --bind='ctrl-a:preview-page-up' \
          --bind='ctrl-u:half-page-up+refresh-preview' \
          --bind='alt-u:page-up+refresh-preview' \
          --bind='ctrl-d:half-page-down+refresh-preview' \
          --bind='alt-d:page-down+refresh-preview' \
          --bind='alt-y:yank' \
          --bind='ctrl-y:kill-line' \
          --bind='alt-g:ignore' \
          --bind='ctrl-g:top' \
          --bind='alt-a:toggle-all' \
          --bind='alt-s:toggle-sort' \
          --bind='alt-h:backward-char+refresh-preview' \
          --bind='alt-l:forward-char+refresh-preview' \
          --bind='ctrl-l:clear-screen'"
        export FZF_DEFAULT_COMMAND="rg -uu \
          --files \
          -H"
        export FZF_ALT_COMMAND="fd -uu -t f"
        export FZF_DEFAULT_OPTS="$FZF_MOVEMENT \
          --bind='ctrl-h:execute(moreman {})' \
          --bind='ctrl-p:toggle-preview' \
          --bind='ctrl-v:execute(nvimpager {})' \
          --tiebreak='length,index' \
          --preview-window 'right:100:wrap:cycle' \
          --height=100 \
          --exact \
          --info='inline' \
          --cycle \
           --reverse \
          --multi \
         --ansi"
        
 if [[ -z "$DISPLAY" ]]; then
   FZF_DEFAULT_OPTS+="
  --color=info:1 \  
        --color=prompt:2 \
    --color=pointer:3 \
  --color=hl+:4 \
  --color=marker:6 \
  --color=spinner:7 \
  --color=header:8 \
   --color=border:9 \
      --color=hl:122 \
        --color=preview-fg:11 \
        --color=fg:13 \
        --color=fg+:14"
   fi

and can even be called indirectly, this second file is where i source all my custom fzf bindings and scripts and functions that get reused by other scripts (including the default options)

        # Setup fzf            
        # ---------            
        PGM="$HOME/project/Man-fzf-scripts"            
        export PGM         
while read line;
    do
      [[ -r "$line" ]] &&  source "${PGM}${line}
done <<EOF   
/fzf/completion.bash            
/fzf/fzf-extra.bash
/fzf/fzf.bind.bash
/fzf/conf/.fzfrc
/fzf/fzf-ide.bash
/fzf/fzcmp      
/fzf/fzf-ide.bash
EOF    
        export FZF_TMUX=1

this functionality exists as is, i just source this from my bashrc or bash.bashrc (or zsh / fish equivalent and there you go config file) ironically its actually named .fzfrc but generally speaking, config files are most of the time just scripts that get executed. hope this gives you some ideals to work with.

as a note FZF_DEFAULT_OPTIONS while used by fzf and may be set by fzf scripts it is actually a shell process so your best place to look for creating configure files would be your shell docs for best practices :).

[j-xella]

Thanks for sharing your config. it is always interesting to see and learn how other people use fzf :)

But I still think that an option to use a config file would be helpful. Here are some reasons that come to my mind stright away:

• config file would be shell-independent. Yes, most modern shells are sh-compatible, but if you have to work with both sh- and csh-like shells, for example, you may need to keep multiple versions of your config
• some shells/systems may have limitations on the variable size. Probably will never hit them, but still, why have a risk factor?
• env var space would be less polluted - after all, only fzf needs FZF_DEFAULT_OPTS, why expose it to everyone?
• config files could be easier to read, and maintain with empty lines and comments. Also, no need to escape various characters just for shell's sake
• future expansion. At some point fzf could have functionality that is difficult to describe via command line arguments. With config file, everything is possible

[rayiik]

hmm i guess my point that I'm trying to scope is without recompiling every time you make a modification im not sure its possible to have an independent of shell config file. However FZF_DEFAULT_OPTIONS, is not just used by fzf, its used by tmux vim and all the various creations that have come after it. the other thing is, with its own compiled config would you still be able to manipulate in in the same way via script (one of the magics of a variable is you can manipulate it per situation. with a config file i don't see how you could do some of the variable hacks that are currently in use by myself and others. (though this could be due to my limited understanding and not an actual limitation)

[fritzrehde]

The problem I face without a (global) config file is that theme switching (light to dark etc.) is impossible. Changing an env variable (FZF_DEFAULT_OPTIONS) will not affect all future fzf instances, spawned from any other terminal (or e.g. sxhkd or tmux on Linux). A global config file can easily be linked to a dark and light theme.

[tuskiie]

struggling with the same thing, did you ever find a solution to this?

[weirdgiraffe]

You can define your own function wrapper for fzf which will source your config file (.fzfrc in this example) on each run. That will keep your environment clean and would allow you to automatically change colorschemes.

Put this sample function into your .zshrc which will effectively wrap the binary:

function fzf() { 
  ( # run in subshell to not pollute top level shell environment
    source ~/.fzfrc
    $(whence -p fzf) "$@"
  )
}

[ivanlan9]

I'm sourcing a file in my .config directory, ~/.config/fzf/fzfdefaults, anyway; it'd be much simpler for me if fzf already knew where to look. And I very much like the idea of making a change to the file and having the new opts take effect immediately, rather than having to source.

IMHO, of course.

[junegunn]

You have some valid points. What do you think about having a separate variable that points to the location of the config file? Because 1. it seems there's no universal agreement on where it should be, and 2. so fzf doesn't have to check for the existence of the file at the default location when it's not used.

# Read config file only if this variable is set
export FZF_DEFAULT_OPTS_FILE=~/.fzfrc

[junegunn]

See #3618

[yujinyuz]

Hi @junegunn

The Ctrl-T and Ctrl-R does not respect the FZF_DEFAULT_OPTS_FILE.

I see that there is a separate FZF_CTRL_T_OPTS

Was this intentional?

[yujinyuz]

@junegunn

Can you try this?

# ~/.config/fzf/config
--layout='reverse-list'
--height='40%'
--info='inline-right'
--color='bg+:#414559,bg:-1,spinner:#f2d5cf,hl:#e78284,gutter:-1'
--color='fg:#c6d0f5,header:#e78284,info:#ca9ee6,pointer:#f2d5cf'
--color='marker:#f2d5cf,fg+:#c6d0f5,prompt:#ca9ee6,hl+:#e78284'

I also created a video. CTRL-R works properly while CTRL-T does not.. you can see if I type fzf the behaviour is correct. But when I press CTRL-T, it doesn't use the reverse list

Screen.Recording.2024-04-17.at.22.19.07.mov

[yujinyuz]

I did try your example with --no-colors and it works but the layout doesn't get applied

echo '--layout=reverse-list' > /tmp/fzf

[junegunn]

That's because the key binding was written before $FZF_DEFAULT_OPTS_FILE was added so it currently doesn't inject the arguments in it to "un-override" its options such as --reverse.

fzf/shell/key-bindings.bash

Lines 17 to 26 in d169c95

	# Key bindings
	# ------------
	__fzf_select__() {
	local opts
	opts="--height ${FZF_TMUX_HEIGHT:-40%} --bind=ctrl-z:ignore --reverse --walker=file,dir,follow,hidden --scheme=path ${FZF_DEFAULT_OPTS-} ${FZF_CTRL_T_OPTS-} -m"
	FZF_DEFAULT_COMMAND=${FZF_CTRL_T_COMMAND:-} FZF_DEFAULT_OPTS="$opts" $(__fzfcmd) "$@" |
	while read -r item; do
	printf '%q ' "$item" # escape special chars
	done
	}

Ideally, we should handle $FZF_DEFAULT_OPTS_FILE as well so it goes like

echo "--reverse ..." > /tmp/opts
cat "$FZF_DEFAULT_OPTS_FILE" >> /tmp/opts 2>&1
FZF_DEFAULT_OPTS_FILE=/tmp/opts
...

But it's painful and we're not there yet. Please use $FZF_DEFAULT_OPTS or $FZF_CTRL_T_OPTS for the time being.

[yujinyuz]

Okay that makes sense. Thanks!

[junegunn]

#3742 is a WIP PR that addresses the issue. Please test it and see if it works for you.

[backpropper]

I'm guessing we should define the export FZF_DEFAULT_OPTS_FILE variable before sourcing the completions or keybindings in shell rc file. But when I do so I get a .fzfrc: invalid command line string error even if my .fzfrc is empty. Can you guide me what could be wrong here?

[tasuki]

I'm running nvim from kitty without a shell. When running fzf in nvim, fzf naturally does not see the variables defined in my ~/.zshrc. So I copy-paste the FZF_DEFAULT_OPTS. Having a separate config file for fzf would be nice!

[junegunn]

• You can create a file put the desired options in it, and define FZF_DEFAULT_OPTS_FILE to point to it so fzf reads it
• I believe you can define an environment variable in your nvim configuration file. In traditional .vimrc, you can just write let $FZF_DEFAULT_OPTS_FILES = '...'. I believe you can also do it in a Lua configuration file though I'm not familiar with that format.

[tasuki]

Ahh, that was mentioned seven times on this page already 🤦

Thank you so much for your help and for your patience!