Re: list-colors style using the more general one

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

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