Re: completion: highlight matching part

[Tomasz Pala <gotar@xxxxxxxxxx>]

On Sat, Aug 02, 2008 at 14:35:56 -0700, Bart Schaefer wrote:

> This is possible with a combination of tricks.  You have to use the
> "list-colors" zstyle rather than setting the ZLS_COLORS variable, and

I was already using this style (which sets ZLS_COLORS eventually):

zstyle ':completion:*' list-colors ${(s.:.)LS_COLORS}

> you have to use "zstyle -e" to set an evaluated style.

I've found that

setopt extendedglob

is also required for this trick to work.

> Here's an example that makes the prefix green and puts a green
> background behind each of the characters that you can type next:

Thanks a lot! I've tweaked it a little.

> autoload -U colors
> colors
> zstyle -e ':completion:*' list-colors \
>   'reply=( "=(#b)(*$PREFIX)(?)*=00=$color[green]=$color[bg-green]" )'
> 
> The first =00 gives the default color (none) for any part of the
> listing that does not match one of the sub-patterns that is enclosed
> in parens.

First thing was to match ($PREFIX) only - this way we colour the right (including when someone types * or any glob)
letters in case when pattern matches more times. Then I've used (#i)
modifier as if $PREFIX matches, there must be some matcher-list
involved for case insensitiveness. And finally use ${PREFIX:+...} for
disabling highlighting when there's no need to match the first letter
(which overrides standard tags: no, fi, di, ln, pi etc.).

> The above doesn't work when completing files in subdirectories, and

($PREFIX:t) copes with that. While '/' is not used within some options
it doesn't break anything.

> something is forcing e.g. executable files to be colored bold green,
> directories red, etc., if there is ANY value at all for list-colors or

These are default GNU ls colors for standard tags - they're supposed to
be "obtained by setting the style to an empty string", but it doesn't
work that way...

> ZLS_COLORS; this must be a bug in the complist module, because the doc
> says any value with a leading equal sign should take precedence.

It takes precedence, I've set reply to:

${PREFIX:+=(#b)(#i)($PREFIX:t)(?)*==$color[red]=$color[green];$color[bold]}:${(s.:.)LS_COLORS}}

and priorities are met (*, =, tags). Apparently 'empty' applies to tags,
not * and = definitions. However it's not what manual states indeed. It
looks like */= are considered apart from tags 'emptiness'.


At the end I wanted to override * expressions (like *.jpg), but didn't
succeed. There are problems with disabling and reenabling backreferences:

${${(s.:.)LS_COLORS}//#(#b)\*(*)=(*)/'=(#Bbi)($PREFIX:t)(?)*('$match[1]')='$match[2]'=$color[red]=$color[green];$color[bold]=$color[cyan];$color[bold]'}

For example:

'=(#Bbi)($PREFIX:t)(?)*(.jpg)(#B)=01;35=31=32;01=36;01 =(#Bbi)($PREFIX:t)(?)*(.gif)(#B)=01;35=31=32;01=34;01
   ^^                         ^^                         ^^                         ^^

in this case *.gif files are matched only after some *.jpg does. Of
course it won't work when full filename is typed and has other issues,
but I abandoned such solution because it's too CPU intensive anyway.


The point is, this works for files and every completions as well:)

> } $ ls abcd[tab]
> } abcd123		abcd456		abcd789
> } abcdefg		abcdhij		abcdklm
> } 
> } and I'd like the 'abcd' to be lightgreen.
> 
> You'll have to work out for yourself what to replace $color[green]
> with, in the example above.  "light green" is not a standard ANSI
> color and the code for it may vary.  Just find the number that your
> terminal uses and insert that above.

$color[bold] was enough. I've end up with (well, typed color codes):

#v+
autoload -U colors
colors

highlights='${PREFIX:+=(#bi)($PREFIX:t)(?)*==$color[red]=$color[green];$color[bold]}':${(s.:.)LS_COLORS}}

zstyle -e ':completion:*' list-colors \
	'reply=( "'$highlights'" )'

unset highlights
$v-

Now I can do:

$ rpm -q *devel[tab]

and clearly see the packages :D  Thanks once more:)

-- 
Tomasz Pala <gotar@xxxxxxxxxxxxx>