list-colors style using the more general one

list-colors style using the more general one

[Sebastian Gniazdowski]

Hello,
I'm using the following zstyle:

zstyle ':completion:*:zplugin:argument-rest:plugins' list-colors
'=(#b)(*)/(*)==1;35=1;33'

It is working fine, i.e. colorizes the completed results, until I also
issue the following zstyle:

zstyle ":completion:*" list-colors “${(s.:.)LS_COLORS}”

Why would a more general style block the more specific one?
-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

Re: list-colors style using the more general one

[Oliver Kiddle]

Sebastian Gniazdowski wrote:
> I'm using the following zstyle:
>
> zstyle ':completion:*:zplugin:argument-rest:plugins' list-colors
> '=(#b)(*)/(*)==1;35=1;33'
>
> It is working fine, i.e. colorizes the completed results, until I also
> issue the following zstyle:
>
> zstyle ":completion:*" list-colors ???${(s.:.)LS_COLORS}???

Does it help if you use ':completion:*:default' as the context here?
And does that affect other things like the directory completion.

If you don't set the group-name style, that could also be important as
complist doesn't know about tags and uses group names.

Looking at the _zplugin on github, I think you should also be declaring
  local curcontext="$curcontext"
at the top of the function. Declaring context local is not needed. This
is because you pass -C to _arguments. This probably doesn't matter but
with it, I have more confidence that the context is correct.

> Why would a more general style block the more specific one?

It wouldn't.

But, if you follow a debug trace from _complete_debug, you should see
it looking up list-colors with many different styles and collating them
all in _comp_colors. The whole of _comp_colors is used at the end.
It will have done a lookup with other contexts that will match *, e.g:
  :completion::complete:zplugin:argument-rest:argument-rest

The final _comp_colors will have ???${(s.:.)LS_COLORS}??? multiple times
and your '=(#b)(*)/(*)==1;35=1;33' entry at the end. I'm not sure why
this doesn't work in spite. There must be something in LS_COLORS that
the complist module then doesn't like. Perhaps some new codes. It'd be
good to track down which exactly. Or perhaps it doesn't like the
duplication.

Oliver

Re: list-colors style using the more general one

[Sebastian Gniazdowski]

On Fri, 18 Oct 2019 at 18:59, Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
>
> Sebastian Gniazdowski wrote:
> > I'm using the following zstyle:
> >
> > zstyle ':completion:*:zplugin:argument-rest:plugins' list-colors
> > '=(#b)(*)/(*)==1;35=1;33'
> >
> > It is working fine, i.e. colorizes the completed results, until I also
> > issue the following zstyle:
> >
> > zstyle ":completion:*" list-colors ???${(s.:.)LS_COLORS}???
>
> Does it help if you use ':completion:*:default' as the context here?

No, it doesn't help

> And does that affect other things like the directory completion.

Not sure how to test this? I've did ls github/<tab>, and there was no change

> If you don't set the group-name style, that could also be important as
> complist doesn't know about tags and uses group names.
>
> Looking at the _zplugin on github, I think you should also be declaring
>   local curcontext="$curcontext"
> at the top of the function. Declaring context local is not needed. This
> is because you pass -C to _arguments. This probably doesn't matter but
> with it, I have more confidence that the context is correct.

I've committed the two changes but it didn't help.

> > Why would a more general style block the more specific one?
>
> It wouldn't.
>
> But, if you follow a debug trace from _complete_debug, you should see
> it looking up list-colors with many different styles and collating them
> all in _comp_colors. The whole of _comp_colors is used at the end.
> It will have done a lookup with other contexts that will match *, e.g:
>   :completion::complete:zplugin:argument-rest:argument-rest
>
> The final _comp_colors will have ???${(s.:.)LS_COLORS}??? multiple times
> and your '=(#b)(*)/(*)==1;35=1;33' entry at the end. I'm not sure why
> this doesn't work in spite.

It is like so. I've added a print to the end of _main_complete, and
the output was:

“... more entries ... (-default-)*.o=2;37 (-default-)*~=2;37
(-default-)*.zsh_history=2;37 (-default-)*.zcompdump=2;37
(-default-)*.bash_history=2;37 (-default-)*.viminfo=2;37 (-default-)”
(-default-)=(#b)(*)/(*)==1;35=1;33

This pointed to the fact – why the quotes around the first entry and
not around the second? They're the Unicode quotes... fixing them helps
– I can see correct highlighting. But should the quotes be disrupting
the completion in such a way that a following, correct entry doesn't
work? And – the first entry was working OK for the things like ls
<tab>.

> There must be something in LS_COLORS that
> the complist module then doesn't like. Perhaps some new codes. It'd be
> good to track down which exactly. Or perhaps it doesn't like the
> duplication.

I've tried two definitions: https://github.com/trapd00r/LS_COLORS and
https://github.com/zpm-zsh/dircolors-material and two had the same
problem (before noticing the Unicode quotes), so that's rather not it.

-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org