PATCH: colors (was: Re: ever-expanding ZLS_COLORS and Tags vs. groups, and ZLS_COLORS)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> On Jun 16,  9:40am, Matthew Lovell wrote:
> } Subject: ever-expanding ZLS_COLORS
> }
> } Now, everytime I attempt a completion which uses zsh-options, it seems
> } ZLS_COLORS just continues to grow
> 
> Yes, I was noticing this myself.  It's happening because some code at the
> top of the _setup function tries to merge your list-colors style with the
> existing global value of $ZLS_COLORS, but then the old value of $ZLS_COLORS
> doesn't get automatically restored when completion is done (the code to do
> the restore in _main_complete is conditional upon $compstate[old_list]).

Oops. The restore is to ensure that lists from _oldlist are coloured
correctly. _setup should reset it if the style isn't set for the
default tag.


In another message, on a different subject:

> } > If we wanted
> } > to solve that, we would have to make _setup get the name of the group
> } > (which may be -default-) as an argument (when called from
> } > _description) and use that name in ZLS_COLORS. But then we would be
> } > back to what I said above.
> 
> But _setup *DOES* get the name of the group as an argument when called
> from _description!  And it DOES use that name in ZLS_COLORS.  Look:

As you said below: this is *NOT* the group name, it's the tag. So, if
we make _setup get the group name, too (as a second argument), we can
use that in setting up ZLS_COLORS. The patch below does this.

> ...
> 
> } > So, we could (quite easily) change it, but that set-for-one-tag-and-
> } > used-for-others-too made me do it in the way we have it now
> 
> Don't ask me how I got from there to here, but:  The problem REALLY is --
> as can begin to be seen in the last line of that trace output -- that the
> value of $ZLS_COLORS is the concatenation of the list-colors styles for
> every tag that has been looked up in the whole completion.  So if any of
> those styles lacks a (group) qualifier, it might be applied to the wrong
> groups.  Hence _setup attempts to be sure that the group qualifier is
> there, with sometimes-inappropriate results.

Exactly (I'm more and more of the opinion that we meant the same all
the time, with me not being able to express that correctly anyway).

> } The problem is really that the code in _setup can't find out what
> } pattern was used when defining the style.
> 
> I don't think that's the problem.  Note in the trace above that we end up
> with `:(argument-1)...:' in $ZLS_COLORS.  That's nonsensical; there's no
> group named `argument-1'.  The problem is that _setup can't differentiate
> between a "real tag" and a group name being used as a tag.  The *right*
> behavior, I think, is for all "real tag" lookups to use `(-default-)' in
> ZLS_COLORS, whereas group names being used as tags use their actual name.
> 
> Can we devise a way to tell _setup whether $1 is a real tag, or a group?
> Treating `default' as the only real tag is just not cutting it.  Or else
> don't try to use _setup to set ZLS_COLORS (see the other bug report about
> how seldom it is being properly reset again).
> 
> Miscellaneous other things that I notice while staring at this:
> 
> Using a sensible-looking style like
> 
>     zstyle ':completion:*:ssh:*' list-colors '(users)=a*=31'
> 
> leads _setup to make the assignment
> 
>     ZLS_COLORS=(argument-1)(users)=a*=31:
> 
> which is syntactic garbage.
> 
> In _description, `_setup "$1"' is called BEFORE the group-name style is
> looked up and used to determine $gname, so you're never guaranteed to get
> the right group name in ZLS_COLORS in spite of all of _setup's efforts.
> 
> } Hrm, maybe we should admit this and use the group name instead of the
> } tag when looking up list-colors.
> 
> It almost seems to me that it should be the other way around -- admit that
> it doesn't work to look up list-colors by group name and require the group
> name to be embedded in parens in the value of the style instead.

I told about several of these things in earlier mails, so I don't want 
to answer them one-by-one.


The patch make _setup get an (optional) second argument, the group
name. In _description, this of course means that gname is set up
before _setup is called. _setup uses that group name in $ZLS_COLORS.

And now everyone can easily have a look at the problem that made me
withhold this (simple) patch:

  zstyle '*:hosts' list-colors '=a*=33'
  zstyle '*' users ich du er alfred
  zstyle '*' hosts alpha beta gamma

Now try `ssh <TAB>'. `alfred' is coloured.

Is this still better than the previous state?


The patch also allows using `(...)...' in list-colors.


Bye
 Sven

Index: Completion/Core/_description
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/_description,v
retrieving revision 1.7
diff -u -r1.7 _description
--- Completion/Core/_description	2000/06/16 07:38:59	1.7
+++ Completion/Core/_description	2000/06/19 08:44:42
@@ -11,7 +11,10 @@
 
 _lastdescr=( "$_lastdescr[@]" "$3" )
 
-_setup "$1"
+zstyle -s ":completion:${curcontext}:$1" group-name gname &&
+    [[ -z "$gname" ]] && gname="$1"
+
+_setup "$1" "${gname:--default-}"
 
 name="$2"
 
@@ -23,8 +26,6 @@
   [[ "$hidden" = all ]] && format=''
   opts=(-n)
 fi
-zstyle -s ":completion:${curcontext}:$1" group-name gname &&
-    [[ -z "$gname" ]] && gname="$1"
 zstyle -s ":completion:${curcontext}:$1" matcher match &&
     opts=($opts -M "$match")
 [[ -n "$_matcher" ]] && opts=($opts -M "$_matcher")
Index: Completion/Core/_setup
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/_setup,v
retrieving revision 1.4
diff -u -r1.4 _setup
--- Completion/Core/_setup	2000/05/31 09:56:12	1.4
+++ Completion/Core/_setup	2000/06/19 08:44:42
@@ -2,12 +2,21 @@
 
 local val nm="$compstate[nmatches]"
 
+[[ $# -eq 1 ]] && 2="$1"
+
 if zstyle -a ":completion:${curcontext}:$1" list-colors val; then
   zmodload -i zsh/complist
   if [[ "$1" = default ]]; then
     ZLS_COLORS="${(j.:.)${(@)val:gs/:/\\\:}}"
   else
-    eval "ZLS_COLORS=\"(${1})\${(j.:(${1}).)\${(@)val:gs/:/\\\:}}:\${ZLS_COLORS}\""
+    local simple grouped
+
+    simple=( "(${2})${(@)^val:#\(*\)*}" )
+    grouped=( "${(M@)val:#\(*\)*}" )
+    simple="${(j.:.)simple}:"
+    grouped="${(j.:.)grouped}:"
+    [[ "$ZLS_COLORS" != *${simple}*  ]] && ZLS_COLORS="${simple}$ZLS_COLORS"
+    [[ "$ZLS_COLORS" != *${grouped}* ]] && ZLS_COLORS="${grouped}$ZLS_COLORS"
   fi
 
 # Here is the problem mentioned in _main_complete.
@@ -16,6 +25,8 @@
 #   zmodload -i zsh/complist
 #   ZLS_COLORS="$ZLS_COLORS$ZLS_COLOURS"
 
+elif [[ "$1" = default ]]; then
+  ZLS_COLORS=
 fi
 
 if zstyle -t ":completion:${curcontext}:$1" list-packed; then
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.67
diff -u -r1.67 compsys.yo
--- Doc/Zsh/compsys.yo	2000/06/16 07:38:59	1.67
+++ Doc/Zsh/compsys.yo	2000/06/19 08:44:44
@@ -1358,13 +1358,14 @@
 If this style is set for the tt(default) tag, the strings in the value 
 are taken as specifications that are to be used everywhere.  If it is
 set for other tags, the specifications are used only for matches of
-the type described by the tag.  For this to work, the tt(group-name)
+the type described by the tag.  For this to work best, the tt(group-name)
 style must be set to an empty string.  If the tt(group-name) tag
 specifies other names for the groups the matches in these groups can
 be colored by using these names together with the `tt((group)...)'
 syntax described for the tt(ZLS_COLORS) and tt(ZLS_COLOURS) parameters 
 and adding the specifications to the value for this style with the
-tt(default) tag.
+tt(default) tag (although in most cases it should work by setting this 
+style for the appropriate tags).
 
 It is possible to use the same specifications set up for the GNU
 version of the tt(ls) command:
@@ -3472,10 +3473,14 @@
 generally used by the completion system.
 )
 findex(_setup)
-item(tt(_setup) var(tag))(
+item(tt(_setup) var(tag) [ var(group) ])(
 This function expects a tag as its argument and sets up the special
 parameters used by the completion system appropriately for the tag,
 using styles such as tt(list-colors) and tt(last-prompt).
+
+The optional var(group) gives the name of the group in which the
+matches will be placed. If it is not given, the var(tag) is used as
+the group name.
 
 Note that this function is called automatically from tt(_description)
 so that one normally doesn't have to call it explicitly.

--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx