Bug: _oldlist and automatic coloring of matched

Bug: _oldlist and automatic coloring of matched

[Julius Plenz]

Hey there,

while I recently created a new zsh configuration from scratch I
stumbled upon a bug in the _oldlist completer. (At least _oldlist
if one of the sources of the problem - other completers might behave
similarly.)

I wanted to configure Zsh not to use colors at all. So I simply didn't
set the 'list-colors' style for the default tag anywhere. This,
however, is not enough in the case of _oldlist. Consider this minimal
zshrc:

    autoload -U compinit && compinit
    zmodload -i zsh/complist
    zstyle ':completion:*' completer _oldlist _complete
    zstyle ':completion:*' menu select select=long-list

If you hit Tab the first time, the listing of filenames is not
colored. But once you hit Tab again (and the _oldlist completer comes
into play) suddenly some matches are colored.

I guess the problem is that _oldlist somehow sets the list-colors
style to '' which then causes Zsh to color the list according to the
default colors. I was, however, not able to trace the source of the
problem any further.

Cheers,
Julius

Re: Bug: _oldlist and automatic coloring of matched

[Bart Schaefer]

On Fri, Apr 23, 2010 at 3:28 PM, Julius Plenz <julius@plenz.com> wrote:
>
>    autoload -U compinit && compinit
>    zmodload -i zsh/complist
>    zstyle ':completion:*' completer _oldlist _complete
>    zstyle ':completion:*' menu select select=long-list
>
> If you hit Tab the first time, the listing of filenames is not
> colored. But once you hit Tab again (and the _oldlist completer comes
> into play) suddenly some matches are colored.

This is actually coming from _main_complete, here:

if [[ "$compstate[old_list]" = keep ]]; then
  ZLS_COLORS="$_saved_colors"
elif (( $#_comp_colors )); then
  ZLS_COLORS="${(j.:.)_comp_colors}"
else
  unset ZLS_COLORS
fi

I guess there should be a second test that $_saved_colors is non-empty
before assigning it to ZLS_COLORS ... but I'm not sure that's correct
either, because we don't know at this point *why* $_saved_colors is
empty, i.e., whether the value when saved was empty or unset.

Re: Bug: _oldlist and automatic coloring of matched

[Peter Stephenson]

On Sat, 24 Apr 2010 10:35:06 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Fri, Apr 23, 2010 at 3:28 PM, Julius Plenz <julius@plenz.com> wrote:
> >
> >    autoload -U compinit && compinit
> >    zmodload -i zsh/complist
> >    zstyle ':completion:*' completer _oldlist _complete
> >    zstyle ':completion:*' menu select select=long-list
> >
> > If you hit Tab the first time, the listing of filenames is not
> > colored. But once you hit Tab again (and the _oldlist completer comes
> > into play) suddenly some matches are colored.
> 
> This is actually coming from _main_complete, here:
> 
> if [[ "$compstate[old_list]" = keep ]]; then
>   ZLS_COLORS="$_saved_colors"
> elif (( $#_comp_colors )); then
>   ZLS_COLORS="${(j.:.)_comp_colors}"
> else
>   unset ZLS_COLORS
> fi
> 
> I guess there should be a second test that $_saved_colors is non-empty
> before assigning it to ZLS_COLORS ... but I'm not sure that's correct
> either, because we don't know at this point *why* $_saved_colors is
> empty, i.e., whether the value when saved was empty or unset.

Should it be something like this?

Index: Completion/Base/Core/_main_complete
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Core/_main_complete,v
retrieving revision 1.11
diff -p -u -r1.11 _main_complete
--- Completion/Base/Core/_main_complete	1 Apr 2009 10:57:12 -0000	1.11
+++ Completion/Base/Core/_main_complete	25 Apr 2010 21:21:25 -0000
@@ -30,7 +30,8 @@ local func funcs ret=1 tmp _compskip for
       _saved_lastprompt="${compstate[last_prompt]}" \
       _saved_list="${compstate[list]}" \
       _saved_insert="${compstate[insert]}" \
-      _saved_colors="$ZLS_COLORS"
+      _saved_colors="$ZLS_COLORS" \
+      _saved_colors_set=${+ZLS_COLORS}
 
 # _precommand sets this to indicate we are following a precommand modifier
 local -a precommands
@@ -325,7 +326,11 @@ fi
     compstate[list]="${compstate[list]//messages} force"
 
 if [[ "$compstate[old_list]" = keep ]]; then
-  ZLS_COLORS="$_saved_colors"
+  if [[ $_saved_colors_set = 1 ]]; then
+    ZLS_COLORS="$_saved_colors"
+  else
+    unset ZLS_COLORS
+  fi
 elif (( $#_comp_colors )); then
   ZLS_COLORS="${(j.:.)_comp_colors}"
 else


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

Re: Bug: _oldlist and automatic coloring of matched

[Bart Schaefer]

On Sun, Apr 25, 2010 at 2:22 PM, Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
> On Sat, 24 Apr 2010 10:35:06 -0700
> Bart Schaefer <schaefer@brasslantern.com> wrote:
>> I guess there should be a second test that $_saved_colors is non-empty
>> before assigning it to ZLS_COLORS ... but I'm not sure that's correct
>> either, because we don't know at this point *why* $_saved_colors is
>> empty, i.e., whether the value when saved was empty or unset.
>
> Should it be something like this?

Yes, that would probably do it, except I believe _saved_colors_set
needs to be declared somewhere.

Re: Bug: _oldlist and automatic coloring of matched

[Peter Stephenson]

On Mon, 26 Apr 2010 09:21:51 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Yes, that would probably do it, except I believe _saved_colors_set
> needs to be declared somewhere.

The first hunk puts it in a "local" statement, which has disappeared off
the top.

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


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom