Open patrick96 opened 4 years ago
Sorry for the late reply.
Yes, it is possible. In fact, it is on my plan.
But the file list given to fzf-tab has no color information. To accomplish this fzf-tab may need to parse LS_COLORS by itself.
To accomplish this fzf-tab may need to parse LS_COLORS by itself.
I was afraid this was the case. Kind of weird that there is no way to get the colors from zsh directly.
There is https://github.com/xPMo/zsh-ls-colors. MIT licensed, so easy to copy stuff over.
@xPMo Maybe you can help?
@Aloxaf Let me know. I think the easiest option would be to bring in my project as a submodule or subtree, and then you can load the functions after EDIT: nope, thanks @romkatv.fpath+=(${0:h}/zsh-ls-colors/lib)
.
If you have any questions, feel free to open an issue over at my project.
This sounds cool but doesn't work in practice for two reasons.
The only safe way to embed another plugin is to copy its sources and rename all symbols.
Yeah, you're right. For (1) subtree would still work afaik. Unfortunately, I don't see a way out of (2).
Oh wait, I do see a way out of (2), hold on.
Unfortunately, I don't see a way out of (2).
I thought of doing it like this in zsh-defer. When you source zsh-defer.plugin.zsh
, you can pass an optional parameter. If you do, all symbols (functions and global parameters) defined by zsh-defer will have this prefix. So, if someone wants to use zsh-defer
in a plugin, they would bundle the unchanged zsh-defer.plugin.zsh
(either as git submodule, subtree, or whatever) and call source zsh-defer.plugin.zsh _my_plugin_
. It would define function _my_plugin_zsh-defer
.
Yeah, I just realized that prefixing would work after posting that, and whipped up a quick fix for it. The sacrifice is that now all the functions have to be in one file instead of autoloaded. But I think it's worth the tradeoff of being able to
source ls-color-subtree/ls-colors.zsh fzf-tab::ls-colors
fzf-tab::ls-colors::init
...
Thanks @romkatv and @xPMo. zsh-ls-colors
is cool, it helps a lot.
A basic support has been done with the help of @xPMo 's zsh-ls-colors
I use https://github.com/trapd00r/LS_COLORS
But I just can’t figure out what needs to be written in .zshrc so that the colors are displayed.
Tried so:
zstyle ':completion:*' list-colors ${(s.:.)LS_COLORS}
But the colors are not displayed correctly and the Symbolic link is not displayed correctly, it can be seen in the screenshot:
If in .zhsrc is not set zstyle ': completion: *' list-colors $ {(s.:.)LS_COLORS}
then the colors are not displayed at all.
@webmastak What is wrong with the colors?
zstyle ':completion:*' list-colors ${(s.:.)LS_COLORS}
This sets the zstyle to the current value of LS_COLORS as far as I know, so you need to call this after you actually set LS_COLORS.
Also @Aloxaf, this works very nicely for me, thank you so much :smiley:
You say this is "basic support", is there anything missing? If not, I think we can close this.
I can confirm that it works as advertised.
I can confirm that it works as advertised.
Understood, I had zstyle ': completion: *: default' list-colors $ {(s.:.)LS_COLORS}
But the symbolic link is buggy:
@webmastak Does the buggy symbolic link go away if you remove the zstyle command?
@webmastak Does the buggy symbolic link go away if you remove the zstyle command?
Figured out.
In the plugin file fzf-tab.zsh you need to replace on line 257:
rsv_color=$reply[2]
with rsv_color=$reply[1]
But the symbolic link is buggy
@webmastak Yes...it's a bug introduced in f81cee85dc1cb955f1dd981f58839a825856073c and has been fixed in https://github.com/Aloxaf/fzf-tab/commit/749e86b28f777a173f7307df312d2a78b8c7c661. I think I should write some tests for it.
You say this is "basic support", is there anything missing? If not, I think we can close this.
@patrick96 An example:
zstyle ':completion:*' list-colors '=(#b)(--[^ ]#)(*)=38;5;220;1=38;5;216'
But I'm not sure how many people need it and whether is it necessary after installing fzf-tab.
I won't try to implement it in the short term. Feel free to close the issue if you don't need it. Then I can put it aside without any pressure. XD
On linux it works perfectly. Does it work on mac os? Right now on catalina zsh 5.7.1 there is no color fzf output of directory listing.
@cradesto I'm not sure. Have you set list-colors correctly?
It seems that yes. Below you can see cleared zshrc (On macosx dircolors is provided as gdircolors by homebrew).
eval "$(dircolors -b)"
source path/to/antigen.zsh
antigen use oh-my-zsh
antigen bundle fzf
antigen bundle Aloxaf/fzf-tab
antigen apply
zstyle ':completion:*:default' list-colors ${(s.:.)LS_COLORS}
On linux this zshrc works ok. But I can't figure out why it doesn't work on macos.
Changes last string to zstyle ':completion:*' list-colors ${(s.:.)LS_COLORS} solves the problem for macos.
This new update is broken on my machine. It emits this error on startup:
/Users/evar/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-Aloxaf-SLASH-fzf-tab/fzf-tab.plugin.zsh:source:15: no such file or directory: /Users/evar/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-zdharma-SLASH-zbrowse/lib/zsh-ls-colors/ls-colors.zsh
I don't want this colorization stuff. I think it should not be the default, as it'll probably slows things down. How can I turn this off?
This new update is broken on my machine. It emits this error on startup:
/Users/evar/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-Aloxaf-SLASH-fzf-tab/fzf-tab.plugin.zsh:source:15: no such file or directory: /Users/evar/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-zdharma-SLASH-zbrowse/lib/zsh-ls-colors/ls-colors.zsh
This looks like a bug in your plugin manager.
I don't want this colorization stuff. I think it should not be the default
It's not on by default.
How can I turn this off?
Don't set list-colors
zstyle.
/Users/evar/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-Aloxaf-SLASH-fzf-tab/fzf-tab.plugin.zsh:source:15: no such file or directory: /Users/evar/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-zdharma-SLASH-zbrowse/lib/zsh-ls-colors/ls-colors.zsh
This looks like a bug in your plugin manager.
Apparently, fzf-tab is following https://zdharma.org/zinit/wiki/zsh-plugin-standard/#1_standardized_0_handling and gets tripped by https://github.com/zdharma/zbrowse/blob/09b4a6e2d0161efbac786cfa60e7161389194dd1/zbrowse.plugin.zsh#L8.
Consider using plain ${(%):-%N}
in fzf-tab, like in all respectable plugins.
@romkatv
This looks like a bug in your plugin manager.
I fixed this issue by changing the order of installations:
antibody bundle Aloxaf/fzf-tab
antibody bundle zdharma/fast-syntax-highlighting
antibody bundle zdharma/zbrowse
Adding this info to the readme will probably be helpful for at least antibody
users.
Mac OS: 11.1
I'm on the verge of giving up, but wanted to share my experience as I got everything to work that I wanted on my machine in relation to zsh, fzf, fzf-tab, zstyle, and the myriad of options therein. The only thing that isn't happening for me is different colors for different columns of output.
The configuration page listed in the README seems to not mention list-colors
but mentions group-colors
. I tried both but it seems that while multiple colors appear horizontally, each particular line in the fzf browser is of the same color.
After brew install coreutils
, I tried to follow along with this stackoverflow answer, but I don't see different colors for different columns as explained.
Is there something obvious I am not doing or have not installed?
I've implemented zstyle lookup in the dev branch of zsh-ls-colors. Currently it doesn't respond with the symlink target (or its colorization). Just trying to figure out the best way to add that back into the new all-in-one function.
@startakovsky Currently, fzf-tab doesn't have the full support of list-colors. That's why this issue is still open.
A basic support has been done with the help of @xPMo 's zsh-ls-colors
I cannot reproduce a colored output like this. I am defined LS_COLORs using https://github.com/trapd00r/LS_COLORS. Without fzf-tab, my files look like this:
However, when I activate fzf-tab it is not colored:
I have this in my .zshrc
zstyle ':completion:*' list-colors ${(s.:.)LS_COLORS}
I've tried setting it up on mac os x and also ubuntu under WSL. I am not that experienced with modifying zstyles, is there a setting I am missing?
I figured out that the issue goes away and the coloring comes back when I disable this plugin that I am using.
https://github.com/rsteube/carapace-bin
Seems to be blocking the color on the completion candidates somehow. Strange enough, it does have color when fzf-tab is turned off, so there should be some color information getting through, but it is probably in a different format.
I figured out that the issue goes away and the coloring comes back when I disable this plugin that I am using.
Have you tried sourcing them in a different order? carapace may be overwriting something that fzf-tab sets up.
I have the same problem. The color data is intact and survives the pass through carapace, but the file detection is not triggered in fzf-tab
.
To be precise the line https://github.com/Aloxaf/fzf-tab/blob/5a81e13792a1eed4a03d2083771ee6e5b616b9ab/fzf-tab.zsh#L62 is false when passed through carapace. If I force the isfile test to true, the colors work as expected.
Unfortunately I don't habe enough grasp of the completion system to make further progress. I have logs of both a run with and without carapace available and can upload/analyze them further id someone can tell me where to look.
The carapace generated completion can be viewed here: https://github.com/rsteube/carapace/blob/103abbf9177b52eee2048e7535645f1ac5453422/example/cmd/_test/zsh.sh#L28
I've dug a bit further and it seems there is a problem with how paths are passed in general: I've recorded a short demo at https://asciinema.org/a/579703.
What you can see is that when you navigate to a sub directory carapace-bin passes the whole path, I think this is closely related to the file colors...
_files
) so in the sense of zsh these are just values.list-colors
does not contain LS_COLORS
, but =(#b)...
style patterns which might not be supported: https://github.com/Aloxaf/fzf-tab/issues/32#issuecomment-599500418.zstyle ':fzf-tab:*' query-string ''
.Can confirm this fixes it!
- carapace does its own file completion and highlighting (not using
_files
) so in the sense of zsh these are just values.list-colors
does not containLS_COLORS
, but=(#b)...
style patterns which might not be supported: Display zstyle list-colors in matches #32 (comment).- Only the current segment is used as display value, but seems the query-string uses the full inserted value. Try
zstyle ':fzf-tab:*' query-string ''
.
Oh nice, yeah I was having the same issue. Thank you!
@rsteube HI and thank you for carapace-bin ! It's such a wonderful QoL ! Can you further elaborate how to fix colors with fzf-tab? I'm newbish, don't really understand the inner workings laid out here.
@rsteube HI and thank you for carapace-bin ! It's such a wonderful QoL ! Can you further elaborate how to fix colors with fzf-tab? I'm newbish, don't really understand the inner workings laid out here.
Not sure if it fixes the colors but this should be added to your .zshrc
:
zstyle ':fzf-tab:*' query-string ''
This plugin is really neat! :smiley:
One thing I cannot get to work is the way files are color coded depending on the type of "file" and its permissions when you use regular zsh completion.
I set
list-colors
like this:When disabling
fzf-tab
the completion looks like this:Notice how the symlink has a different color. Now with
fzf-tab
enabled that color is not displayed:Is it possible to have this functionality with
fzf-tab
? I have not found any option that would do something like that and I have also looked through the source code and tried to figure out if and where this color information would be provided by_fzf_tab_orig_widget
but I couldn't find a place where those colors appear.