Closed bradleyfrank closed 1 year ago
I decided to be explicit and add zstyle ":fzf-tab:*" fzf-flags --color=hl:33
which fixed it! Curious though why this still might be happening.
It is expected.
Commandline arguments have higher priority than environment variable. So you have to use fzf-flags
to overwrite fzf-tab's default setting.
I came across this problem in my own setup and thankfully I found this issue.
It does seem that explicitly setting the hl
color in fzf-flag
does remedy this for now. So Thanks!
Though, I'd much rather it inherit the values I've set in FZF_DEFAULT_OPTS
to avoid defining the value in multiple places in such a hack-y fashion.
Before finding this issue, I did grep for hl
and I tried deleting the following line.
https://github.com/Aloxaf/fzf-tab/blob/c7fb028ec0bbc1056c51508602dbd61b0f475ac3/lib/-ftb-fzf#L88
This does allow me to set the hl
color as I please without any "noticeable" side effects, but I didn't do any rigorous testing and struggle to understand the intended purpose of this condition. Why enforce the values of a full or dull white if there are/not header-lines or categories present?
Describe the bug
It seems the
hl
color will not match my settings. No matter what I change it to, the highlight color is stuck at white. I've tried this in multiple terminals to be sure (Apple Terminal, Hyper, Kitty).I can make sure:
compinit
To Reproduce
Steps to reproduce the behavior:
hl
colorcd
into directoryhl
colorExpected behavior
Substring matches should be the color defined by
hl
.Screenshots
With
export FZF_DEFAULT_OPTS='--color info:33,prompt:33,pointer:166,marker:166,spinner:33,fg:234:regular,fg+:232:regular,bg+:251:regular,hl:33:bold,hl+:33:regular'
With
export FZF_DEFAULT_OPTS='--color ...hl:200:reverse...'
Environment:
Minimal zshrc
https://gist.github.com/bradleyfrank/a9b81d10fe380bee251ac2e610103daf
Log
If applicable, use
C-x .
to trigger completion and provide the log.