[BUG] Fzf color setting for "hl" seems to be not respected

idevat commented 1 year ago

Describe the bug

Color of highlighted characters (on not selected line - i.e. hl) does not respect settings for fzf and it is highlighted with unreadable color. See screenshot (fzf-tab on left side with gray characters and standalone fzf on right side with red characters)

I can make sure:

[x] I am using the latest version of fzf-tab
[x] this is the minimal zshrc which can reproduce this bug
[x] fzf-tab is loaded after compinit
[x] fzf-tab is loaded after plugins which will wrap Tab, like junegunn/fzf/completion.zsh
[x] fzf-tab is loaded before zsh-autosuggestions, zsh-syntax-highlighting and fast-syntax-highlighting.

To Reproduce

Steps to reproduce the behavior:

Use the attached config
Type 'vi '
Press Tab
See the highlight color

Expected behavior

The color of highlighted characters are the same as in standalone fzf.

Screenshots

Screenshot_fzf_tab

Environment:

OS: linux (ubuntu)
zsh version: zsh 5.8 (x86_64-ubuntu-linux-gnu)

Minimal zshrc

PROMPT='%K{#eeeeee}%F{#1976d2}%~%K{#eeeeee} %F{33}$%f%k '

autoload -U compinit
zstyle ':completion:*' menu select
zmodload zsh/complist
compinit
# include hidden files
_comp_options+=(globdots)

autoload bashcompinit
bashcompinit

export FZF_DEFAULT_OPTS=$FZF_DEFAULT_OPTS'
  --color=fg:#111111,bg:#ffffff,hl:#c62828
  --color=fg+:#1a237e,bg+:#EEEEEE,hl+:#b71c1c
  --color=info:#80cbc4,prompt:#b71c1c,pointer:#ab47bc
  --color=marker:#66bb6a,spinner:#ab47bc,header:#90a4ae'

source ~/.zsh/plugin/fzf-tab/fzf-tab.plugin.zsh
zstyle ':completion:*:git-checkout:*' sort false
zstyle ':completion:*:descriptions' format '[%d]'
zstyle ':completion:*' list-colors ${(s.:.)LS_COLORS}
zstyle ':fzf-tab:complete:cd:*' fzf-preview 'exa -1 --color=always $realpath'
zstyle ':fzf-tab:*' switch-group ',' '.'

quicknir commented 1 year ago

Are you sure fzf-tab respects FZF_DEFAULT_OPTS? I think you need to set the fzf-flags style instead.

quicknir commented 1 year ago

I'm extremely confused actually because after I posted this, I saw that it's the fzf binary itself which documents FZF_DEFAULT_OPTS. So, by default anything that ultimately uses the fzf binary ought to respect those arguments. So I thought I was right about your issue. But then I just tested it locally and indeed I see that FZF_DEFAULT_OPTS is not being respected. I guess the authors of fzf-tab preferred to avoid this global completely in favor of zstyle.

You can force fzf-tab to accept the default opts by doing

zstyle ':fzf-tab:*' fzf-flags $(echo $FZF_DEFAULT_OPTS)

I do this in my setup because ultimately, since the default options are used widely, all that FZF_DEFAULT_OPTS ends up containing is colors and the matching style (-e).

idevat commented 1 year ago

Thank you @quicknir for explanation and solution! I confirm that your solution works.

quicknir commented 1 year ago

@idevat okay, the full answer is even more complicated. fzf-tab does respect FZF_DEFAULT_OPTS, but it surrounds the value in the shell that tmux was launched from. not in tmux itself. So, if you want to see the change in FZF_DEFAULT_OPTS, and you, like me are currently editing your zsh environment files inside tmux, you need to:

completely exit tmux.
open a fresh shell at the terminal emulator level.
Launch tmux. Now you should observe fzf-tab respecting FZF_DEFAULT_OPTS.

I'm guessing that like me, you simply edited your zshrc, opened a new tmux tab, and then observed that fzf-tab wasn't respecting it. It's because it takes its value from the outside. fzf itself I think is more careful in the implementation of fzf-tab and properly forwards this env var.

Aloxaf / fzf-tab