issues when coloring only descriptions in menu list

issues when coloring only descriptions in menu list

[apfelsinenhain]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

Hello.

I wanted to have a different colour for the per-match descriptions in 
the menu list, but I can't get it to work in all cases.

- start a clean shell with `zsh -f`

- execute:
  > zmodload zsh/complist
  > autoload -U compinit && compinit
  >
  > zstyle ':completion:*' list-separator "XX"
  > zstyle ':completion:*:default' list-colors '=XX*=31'
  >
  > _a () {
  >     _arguments \
  >       '(--first -f)'{--first,-f}'[first should be red]' \
  >       '--second[second should be red]'
  > }
  > compdef _a a

- try:
   - `a -<tab>`  WILL show color
   - `a --<tab>` will NOT show color

This doesn't just happen when using `_arguments`. Using `_describe` and 
those specific zstyle's also doesn't work.

Screenshots + more tests & examples can be found here:
https://gist.github.com/Orangenhain/c9ac6ea47f187589813b9887c300a897

Is that a bug? Am I using list-colors wrong?

Thanks.

Re: issues when coloring only descriptions in menu list

[Daniel Shahaf]

apfelsinenhain@gmx.de wrote on Mon, Apr 17, 2017 at 19:02:15 +0200:
>  > zstyle ':completion:*' list-separator "XX"
>  > zstyle ':completion:*:default' list-colors '=XX*=31'
>
> - try:
>   - `a -<tab>`  WILL show color
>   - `a --<tab>` will NOT show color

Not sure whether it's a bug, but this setting seems to work:

    zstyle ':completion:*:default' list-colors '=(#b)*(XX*)==31'

Re: issues when coloring only descriptions in menu list

[Bart Schaefer]

On Apr 17,  7:02pm, apfelsinenhain@gmx.de wrote:
}
} I wanted to have a different colour for the per-match descriptions in 
} the menu list, but I can't get it to work in all cases.
} 
}   > zstyle ':completion:*' list-separator "XX"
}   > zstyle ':completion:*:default' list-colors '=XX*=31'
[...]
}    - `a -<tab>`  WILL show color
}    - `a --<tab>` will NOT show color

I'm puzzled why the FIRST of those cases works, because I would expect
you to need this:

    zstyle ':completion:*:default' list-colors '=(#b)*(XX*)=0=31'

which does work for both cases.  Something about having both --first
and -f as matches is causing the "display string" against which the
pattern is compared to start only after the two columns of matches,
whereas when there is only a single column of matches each full line
becomes one "display string".

Re: issues when coloring only descriptions in menu list

[Bart Schaefer]

On Apr 17, 11:52am, Bart Schaefer wrote:
}
} I'm puzzled why the FIRST of those cases works, because I would expect
} you to need this:
} 
}     zstyle ':completion:*:default' list-colors '=(#b)*(XX*)=0=31'

This demonstrates what is going on:

    autoload compinit && compinit -D -u

    zstyle ':completion:*' list-separator "XX"
    zstyle ':completion:*:default' list-colors '=(#b)*(XX*)(?)==31=33;40'

    _a () {
      _arguments \
	{--first,-f}'[first should be red]' \
	'--barXXfoo[watch what happens here]' \
	'--second[second should be red]'
    }
    compdef _a a

Now try TAB after each of "a -" and "a --" and watch where the black
background appears.

I think this has something to do with padding the columns when there
is more than one match to put on the same line.

Re: issues when coloring only descriptions in menu list

[apfelsinenhain]

[-- Attachment #1: Type: text/plain, Size: 937 bytes --]

Interesting ... this seemed to work at first for me, but further testing 
seems to turn up an issue as well.
If I try to specify a colour for the non-match part of the pattern, then 
for `a -><tab>` I *do* see the description in red, but the non-match 
part isn't coloured ... for the other test cases (`a --` & b & c) it 
does show both colors correctly.

Screenshot: 
https://cloud.githubusercontent.com/assets/168694/25103774/0a3122f0-23be-11e7-9ded-ef60067621a7.png

On 17 Apr 2017, at 20:05, Daniel Shahaf wrote:

> apfelsinenhain@gmx.de wrote on Mon, Apr 17, 2017 at 19:02:15 +0200:
>>> zstyle ':completion:*' list-separator "XX"
>>> zstyle ':completion:*:default' list-colors '=XX*=31'
>>
>> - try:
>>   - `a -<tab>`  WILL show color
>>   - `a --<tab>` will NOT show color
>
> Not sure whether it's a bug, but this setting seems to work:
>
>     zstyle ':completion:*:default' list-colors '=(#b)*(XX*)==31'

Re: issues when coloring only descriptions in menu list

[apfelsinenhain]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

In response to Bart Schaefer's message 
http://www.zsh.org/mla/users/2017/msg00331.html

I've tried what you described, and also added a colour for the non-match 
part ... that gets even more fun, because the colour shows up for the 
option that contains the match, but not others:
https://cloud.githubusercontent.com/assets/168694/25104671/85b5e3fe-23c1-11e7-9b3d-2b65352ff06c.png


---
Sorry, his response came in before I had confirmed my mail address for 
this mailing list. I didn't get his response via mail, and thus can't 
properly reply to it.

Re: issues when coloring only descriptions in menu list

[Bart Schaefer]

On Apr 17,  1:12pm, Bart Schaefer wrote:
}
} This demonstrates what is going on:

Apparently I should have explained a bit more thoroughly.

The tl;dr of this is that the list-colors patterns have to be able to
properly color completions (alone), descriptions (alone but with lots
of trailing whitespace), or single lines consisting of a completion
followed by a description.  This can be done either by using more than
one pattern or by clever use of backreferences.

Read on for too much detail.

}     _a () {
}       _arguments \
} 	{--first,-f}'[first should be red]' \
} 	'--barXXfoo[watch what happens here]' \
} 	'--second[second should be red]'
}     }

The list-colors style is documented as using a pattern that is matched
against the "display strings" in the completion listing.  However, what
exactly constitutes a "display string" is not well-described.

Given the above call to _arguments, when TAB is pressed after a single
hyphen ("a -") the following display elements (I'm carefully not yet
naming them "display strings") are generated:

    --first                     (potential completion)
    first should be red         (description of --first)
    -f                          (potential completion)
    first should be red         (description of -f)
    --barXXfoo			(etc.)
    watch what happens here
    --second
    second should be red

The descriptions are then examined to see if there are any completions
that share the same description.  If there are, those elements are to be
grouped together.  So we end up with

    --first                     (potential completion, group 1)
    -f                          (potential completion, group 1)
    first should be red         (description of group 1)
    --barXXfoo			(group 2)
    watch what happens here     (description of group 2)
    --second                    (etc.)
    second should be red

These are next examined to determine how to put them in columns.  The
result is that we need three columns, two for completions (--first and
-f appearing together) and one for descriptions.  Some lines will not
have all three columns, so the first column in those lines must be
padded to the width of the two columns in the other line to keep the
third column visually stacked.

Next it's determined how to lay these out on the screen, with the
requirement that the third column must have the list-seprator added
at the beginning.  Because of the alignment requirement for the
third column, the preceding columns in each of the other lines must
be handled separately.

Here's where we get into "display strings":  In order to solve the
alignment problem, the display is broken into seven "display strings"
corresponding to the seven elements in my second list above, and
then those are arranged in their sorted order and with appropriate
padding so that the the correct number of lines with the correct
alignment of columns is produced when the seven elements are printed,
in that order, left-to-right (wrap) left-to-right (etc.)

The third column (description) is padded on the right with spaces in
order to force wrapping to occur at the correct position.  This can be
see when colors are added (next step) by setting the background color
of the last character.

Finally the list-colors pattern is matched against each of those seven
strings.  *(XX*)(?) matches "--barXXfoo" and "XX watch what happens here"
but does not match "--first" and does not match "-f".  Then it matches
"XX first should be red", and so on.

So you get no color on the things not matched, and colors on those that
are matched.

If instead TAB is pressed after "a --", we get

    --first
    first should be red
    --barXXfoo
    watch what happens here
    --second
    second should be red

There's no duplication here, so there's no need to break this up into
multiple columns.  Everything needed can be done in one line per
potential completion, just by inserting proper padding before the
list-separator.  So this is minimized to use only one "display string"
per line, "--barXXfoo  XX watch ...", "--first    XX first ..." etc.
The pattern *(XX*)(?) is then matched against those three strings and
matches all of them, with the leading * greedily consuming the first
"XX" in the "--barXXfoo" line so it's not part of the (XX*) reference
and therefore is not colored.

The latter is what I thought would be happening in both cases, when I
made my first reply.

There's an additional complication mentioned in a previous thread (I
forget whether on -workers or -users) that the complist module assumes
the default list-colors foreground+background will always be the same
as the default terminal foreground+background and so does not assert
color changes in all necessary cases when list-colors has been told to
use something else for one of those defaults.  Fortunately you're not
also tickling that one or things would be even harder to explain.

-- 
Barton E. Schaefer