gmane.comp.shells.zsh.user

Tomasz Pala | 1 Aug 18:29

completion: highlight matching part

Hi,

is it possible for zsh to highlight (bold, change color etc.) of
matching part of available completions? E.g.

$ ls abcd[tab]
abcd123		abcd456		abcd789
abcdefg		abcdhij		abcdklm

and I'd like the 'abcd' to be lightgreen.

Now it's sometimes hard to find out what character to type next, this
solution would make it easier.

--

-- 
Tomasz Pala <gotar <at> pld-linux.org>

Peter Menzel | 1 Aug 20:46

Re: completion: highlight matching part

Hi,

2008/8/1 Tomasz Pala <gotar <at> polanet.pl>:
> Now it's sometimes hard to find out what character to type next, this
> solution would make it easier.

I don't know the answer to your question, but that's one of the main
reasons why I switched from bash to zsh, because I find it more then
annoying to find out which character to type next. One can just
continue hitting TAB if the shell encounters multiple alternatives and
cycle through the files (or using cursor keys to navigate right to the
desired file).

best, Peter

Bart Schaefer | 2 Aug 23:35

Re: completion: highlight matching part

On Aug 1,  6:33pm, Tomasz Pala wrote:
}
} is it possible for zsh to highlight (bold, change color etc.) of
} matching part of available completions?

This is possible with a combination of tricks.  You have to use the
"list-colors" zstyle rather than setting the ZLS_COLORS variable, and
you have to use "zstyle -e" to set an evaluated style.

The really hard part is deciphering the documentation for list-colors,
which doesn't have much in the way of examples.

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

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.

The above doesn't work when completing files in subdirectories, and
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
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.

(Continue reading)

Tomasz Pala | 3 Aug 13:14

Re: completion: highlight matching part

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.

(Continue reading)

Bart Schaefer | 3 Aug 19:31

Re: completion: highlight matching part

On Aug 3,  1:14pm, Tomasz Pala wrote:
}
} > 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.

Shouldn't be (if it were, it wouldn't have worked for me, because I
don't have that set).  The complist module sets/restores extendeglob
internally before interpreting the pattern.

I suspect you've got quoting wrong in the reply= assignment when
setting up your zstyle.  There's also an erroneous ":" and extra "}"
in what you say you ended up with.  I think you need:

highlights='${PREFIX:+=(#bi)($PREFIX:t)(?)*=00=$color[red]=$color[green];$color[bold]}'
zstyle -e ':completion:*' list-colors \
    'reply=( "$highlights" ${(s.:.)LS_COLORS} )'

} 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.

Good catch; I wondered about that after I sent the mail.  I was thinking
backward about which string was going to be matched against, in that I
thought the pattern might have to account for a directory-name prefix,
which is also why I missed this ...

(Continue reading)

Peter Stephenson | 3 Aug 23:54

Re: completion: highlight matching part

On Sun, 03 Aug 2008 10:31:17 -0700
Bart Schaefer <schaefer <at> brasslantern.com> wrote:
> On Aug 3,  1:14pm, Tomasz Pala wrote:
> }
> } > 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.
> 
> Shouldn't be (if it were, it wouldn't have worked for me, because I
> don't have that set).  The complist module sets/restores extendeglob
> internally before interpreting the pattern.

I just added this recently, however.

2008-07-05  Peter Stephenson  <p.w.stephenson <at> ntlworld.com>

	* 25266: Doc/Zsh/mod_complist.yo, Src/Zle/complist.c: always use
	EXTENDED_GLOB for patterns in ZLS_COLORS.

Until now it didn't set extendedglob; it needed it, but the manual
didn't say you needed to set it.

--

-- 
Peter Stephenson <p.w.stephenson <at> ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

(Continue reading)

Bart Schaefer | 4 Aug 00:42

Re: completion: highlight matching part

On Aug 3, 10:54pm, Peter Stephenson wrote:
}
} Until now it didn't set extendedglob; it needed it, but the manual
} didn't say you needed to set it.

But the completion system sets extendedglob internally, so it should
always have worked for the list-colors style ...?

Bart Schaefer | 4 Aug 01:31

Re: completion: highlight matching part

On Aug 3, 10:31am, Bart Schaefer wrote:
}
} There's also an erroneous ":" and extra "}"
} in what you say you ended up with.  I think you need:
} 
} highlights='${PREFIX:+=(#bi)($PREFIX:t)(?)*=00=$color[red]=$color[green];$color[bold]}'
} zstyle -e ':completion:*' list-colors \
}     'reply=( "$highlights" ${(s.:.)LS_COLORS} )'

Now it's my turn to have the quoting wrong.  Need another '"..."' in there.

zstyle -e ':completion:*' list-colors \
    'reply=( "'"$highlights"'" ${(s.:.)LS_COLORS} )'

} However, I suspect you think you want this:
} 
}  ${${(s.:.)LS_COLORS}//#(#b)\*(*)=(*)/'=(#bi)($PREFIX:t)(?)(#B)*('$match[1]')='$match[2]'=$color[red]=$color[green];$color[bold]=$color[cyan];$color[bold]'}

Messed that one up, too, I think.  I miscounted the number of "=" as
compared to the number of subexpressions.  I still think you ought to
leave "(#B)" out of there entirely, but the place for it is really after
$match[1] like this:

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

Bart Schaefer | 4 Aug 02:33

Re: completion: highlight matching part

[> workers]

On Aug 3, 10:31am, Bart Schaefer wrote:
} Subject: Re: completion: highlight matching part
}
} The complist module installs some defaults if $LS_COLORS is empty.  The
} problem is that the form beginning with an equal or a star is supposed
} to take precedence over those defaults, but it does not.  Instead (if
} I'm reading the code correctly) it takes precedence only over explicit
} settings of all the possible $LS_COLORS colorings.

I've tracked this (by a much more roundabout route than necessary) to
PWS's patch 25006, in which he asserts (for compatibility with GNU ls)
that "File type tests from stat should come before extension tests."

The documentation still says that extension tests win and file type
tests come last, so this should have been changed at the same time
that complist.c was modified.  But clearly in this instance we want
pattern tests to take precedence over file type tests.  I don't think
there's any equivalent in GNU ls to this particular zsh-ism, so we
have several choices:

(1) Change complist.c:putfilecol() so that pattern tests come first,
    then mode tests, and finally extension tests.

(2) Do something convoluted where we check for an extension match,
    but if we find one, try the mode tests before returning the
    extension color.  We end up with a sort of rock-paper-scissors
    behavior, where modes beat extensions beat patterns beat modes.

(Continue reading)

Peter Stephenson | 4 Aug 21:44

Re: completion: highlight matching part

On Sun, 03 Aug 2008 17:33:21 -0700
Bart Schaefer <schaefer <at> brasslantern.com> wrote:
> (1) Change complist.c:putfilecol() so that pattern tests come first,
>     then mode tests, and finally extension tests.

I should think this is the right thing to do, isn't it?

--

-- 
Peter Stephenson <p.w.stephenson <at> ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Bart Schaefer | 5 Aug 01:54

Re: completion: highlight matching part

On Aug 4,  8:44pm, Peter Stephenson wrote:
} Subject: Re: completion: highlight matching part
}
} On Sun, 03 Aug 2008 17:33:21 -0700
} Bart Schaefer <schaefer <at> brasslantern.com> wrote:
} > (1) Change complist.c:putfilecol() so that pattern tests come first,
} >     then mode tests, and finally extension tests.
} 
} I should think this is the right thing to do, isn't it?

I agree, but wanted to mention the other options because this is arguably
the most distant from what zsh used to do (before workers/25006).

Bart Schaefer | 5 Aug 02:16

Re: completion: highlight matching part

On Aug 4,  4:54pm, Bart Schaefer wrote:
} Subject: Re: completion: highlight matching part
}
} On Aug 4,  8:44pm, Peter Stephenson wrote:
} } Subject: Re: completion: highlight matching part
} }
} } On Sun, 03 Aug 2008 17:33:21 -0700
} } Bart Schaefer <schaefer <at> brasslantern.com> wrote:
} } > (1) Change complist.c:putfilecol() so that pattern tests come first,
} } >     then mode tests, and finally extension tests.
} } 
} } I should think this is the right thing to do, isn't it?
} 
} I agree

Here's the patch, mostly so you can proof my doc change.

Index: Doc/Zsh/mod_complist.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/mod_complist.yo,v
retrieving revision 1.24
diff -u -r1.24 mod_complist.yo
--- Doc/Zsh/mod_complist.yo	5 Jul 2008 19:55:29 -0000	1.24
+++ Doc/Zsh/mod_complist.yo	5 Aug 2008 00:15:00 -0000
@@ -103,9 +103,9 @@
 pattern; the tt(EXTENDED_GLOB) option will be turned on for evaluation
 of the pattern.  The var(value) given for this pattern will be used for all
 matches (not just filenames) whose display string are matched by
-the pattern.  Definitions for both of these take precedence over the
-values defined for file types and the form with the leading asterisk

(Continue reading)

Peter Stephenson | 5 Aug 10:13

Re: completion: highlight matching part

Bart Schaefer wrote:
> On Aug 4,  4:54pm, Bart Schaefer wrote:
> } Subject: Re: completion: highlight matching part
> }
> } On Aug 4,  8:44pm, Peter Stephenson wrote:
> } } Subject: Re: completion: highlight matching part
> } }
> } } On Sun, 03 Aug 2008 17:33:21 -0700
> } } Bart Schaefer <schaefer <at> brasslantern.com> wrote:
> } } > (1) Change complist.c:putfilecol() so that pattern tests come first,
> } } >     then mode tests, and finally extension tests.
> } } 
> } } I should think this is the right thing to do, isn't it?
> } 
> } I agree
> 
> Here's the patch, mostly so you can proof my doc change.

I can't see any problem.  I think it's one of those things (like
DEBUG_BEFORE_CMD) where nobody knew it wasn't the best way of doing it
until they tried it.

--

-- 
Peter Stephenson <pws <at> csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Rocky Bernstein | 5 Aug 12:30

Re: completion: highlight matching part

On Tue, Aug 5, 2008 at 4:13 AM, Peter Stephenson <pws <at> csr.com> wrote:
> Bart Schaefer wrote:
>> On Aug 4,  4:54pm, Bart Schaefer wrote:
>> } Subject: Re: completion: highlight matching part
>> }
>> } On Aug 4,  8:44pm, Peter Stephenson wrote:
>> } } Subject: Re: completion: highlight matching part
>> } }
>> } } On Sun, 03 Aug 2008 17:33:21 -0700
>> } } Bart Schaefer <schaefer <at> brasslantern.com> wrote:
>> } } > (1) Change complist.c:putfilecol() so that pattern tests come first,
>> } } >     then mode tests, and finally extension tests.
>> } }
>> } } I should think this is the right thing to do, isn't it?
>> }
>> } I agree
>>
>> Here's the patch, mostly so you can proof my doc change.
>
> I can't see any problem.  I think it's one of those things (like
> DEBUG_BEFORE_CMD) where nobody knew it wasn't the best way of doing it
> until they tried it.

Interesting. You mean there isn't going to be an option to keep
compatibility with prior versions of zsh?  
>
> --
> Peter Stephenson <pws <at> csr.com>                  Software Engineer
> CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
> Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

(Continue reading)

Peter Stephenson | 5 Aug 12:49

Re: completion: highlight matching part

"Rocky Bernstein" wrote:
> Interesting. You mean there isn't going to be an option to keep
> compatibility with prior versions of zsh?  

This is buried right down in the details of completion where teams of
scientists have worked for years to determine what's actually going on
and where no one else dares to change anything.  It's hard enough
keeping it compatible with itself.  I certainly don't put this in the
same class as features directly visible to the normal shell programmer.

--

-- 
Peter Stephenson <pws <at> csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Return

Return to gmane.comp.shells.zsh.user.

Advertisement

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane