Fzf: CTRL_R doesn't pick up DEFAULT_OPTS

[ahmedelgabri]

• Category
  
  
  
  • [x] fzf binary
  
  
  • [x] Key bindings
  
  
• OS
  
  
  
  • [x] Mac OS X
  
  
• Shell
  
  
  
  • [x] zsh
  
  

I have --reverse in my FZF_DEFAULT_OPTS but CTRL_R doesn't respect this anymore in the latest release. CTRL_T picks it up though

[junegunn]

The code: https://github.com/junegunn/fzf/blob/0.16.1/shell/key-bindings.bash#L59

I decided to override --reverse in $FZF_DEFAULT_OPTS by setting --no-reverse after it as it seemed more fitting for the use case. But as you can see, you can re-override the config using $FZF_CTRL_R_OPTS.

(Nevermind the extra --reverse before $FZF_DEFAULT_OPTS, it was an oversight.)

[ahmedelgabri]

I decided to override --reverse in $FZF_DEFAULT_OPTS by setting --no-reverse after it as it seemed more fitting for the use case.

But it just makes $FZF_DEFAULT_OPTS more confusing. Because people (or at least myself) will assume that $FZF_DEFAULT_OPTS will affect every fzf action. But applying it to some commands only is not really consistent IMO.

[junegunn]

I can see that it can be controversial or confusing, but let me explain. Defaults are just defaults and it should be possible to override some of the options. For example, imagine that you have --multi in $FZF_DEFAULT_OPTS, should we still allow multiple selections in CTRL-R? It will break the function processing the output which expects just a single line from fzf. Likewise, one can have --preview 'cat {}' in $FZF_DEFAULT_OPTS, but fzf may be not filtering files but a list of processes, host names, etc.

But applying it to some commands only is not really consistent IMO.

To be clear, $FZF_DEFAULT_OPTS is applied to every fzf process, it's that we can override a subset of the options by explicitly stating it as the arguments to fzf.

export FZF_DEFAULT_OPTS='--height 50% --reverse'

# Override --height, but --reverse is still applied
fzf --height 30%

Anyway, back to the subject, the case of --reverse option is not equivalent to the examples I gave above, in that it does not affect the correctness, but only affects the presentation style, which should be probably, primarily decided by the user?

[ahmedelgabri]

To be clear, $FZF_DEFAULT_OPTS is applied to every fzf process, it's that we can override a subset of the options by explicitly stating it as the arguments to fzf.

export FZF_DEFAULT_OPTS='--height 50% --reverse'

# Override --height, but --reverse is still applied
fzf --height 30%

I understand, but this doesn't work with $FZF_CTRL_R_OPTS for example, which breaks the predictability of the settings. For something like --multi I understand that it can break some commands, maybe docs to indicate which flags are allowed in $FZF_DEFAULT_OPTS?

Anyway, back to the subject, the case of --reverse option is not equivalent to the examples I gave above, in that it does not affect the correctness, but only affects the presentation style, which should be probably, primarily decided by the user?

Totally agree, it's just that I expect that when I override it in $FZF_DEFAULT_OPTS that it will work as expected. For example my preference is to use --reverse as a default but now I need to add it in multiple places. Which feels a bit odd IMO.

My main issue is already fixed & I understand why, so I'll close this.

Just to be clear, I'm not complaining or anything. I do appreciate your work & thanks for the great tools 😊

[junegunn]

I understand, but this doesn't work with $FZF_CTRL_R_OPTS for example, which breaks the predictability of the settings.

Agreed, we should carefully order the options so that it makes most sense. To summarize:

1. $FZF_DEFAULT_OPTS
   
   
   
   • Options that are context-free (regardless of the type of the entities).
   
   
   • Mostly options that determine presentation style.
   
   
2. $FZF_[BINDING_NAME]_OPTS
   
   
   
   • Per-binding overrides. e.g. Have --reverse in $FZF_DEFAULT_OPTS, and --no-reverse only in $FZF_CTRL_R_OPTS
   
   
3. Options that can affect the correctness should come last

And now I agree that it is more straightforward that we don't override --reverse in CTRL-R.

[junegunn]

Updated, thanks for the comments.