Tags vs. groups, and ZLS_COLORS (Re: wish for a colored completion system)

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Jun 13, 11:25am, Sven Wischnowsky wrote:
} Subject: Re: wish for a colored completion system
}
} Bart Schaefer wrote:
} 
} > I didn't ask why
} > 
} >     zstyle ':completion:*:ssh:*:hosts' list-colors '=a*=31'
} > 
} > doesn't work.  I asked why
} > 
} >     zstyle ':completion:*:ssh:*' list-colors '=a*=31'
} > 
} > doesn't work.
} 
} ;-) I understood that -- and noticed that the part you quoted doesn't
} answer the question. That's why the next paragraph started the way it
} did:
} 
} > And to come back to the question, the completion code only looks up
} > the style with the tag in the context and it can't find out that the
} > pattern used in the definition doesn't contain the tag.

I've been re-reading this explanation at least once a day for the past
four days, and it still doesn't make any sense to me.

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

+_alternative:28:while for then: _description hosts expl remote host name
+_description:3: local name gropt=-J format gname hidden hide match opts
+_description:5: opts=( ) 
+_description:7:if: [[ hosts == -([12]|)[VJ] ]]
+_description:12: _lastdescr=(  remote host name remote host name ) 
+_description:14: _setup hosts
+_setup:3: local val nm=0
+_setup:5:if: zstyle -a :completion::complete:ssh:argument-1:hosts list-colors val
+_setup:6:then: zmodload -i zsh/complist
+_setup:7:then if: [[ hosts == default ]]
+_setup:10:then else: eval ZLS_COLORS="(hosts)${(j.:(hosts).)${(@)val:gs/:/\\:}}:${ZLS_COLORS}"
+_setup:10:then else: ZLS_COLORS=(hosts):(argument-1): 

[I didn't happen to have a list-colors style set when generating that trace,
but that doesn't matter.]

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

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

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net