From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23747 invoked from network); 18 Jun 2000 04:42:47 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 18 Jun 2000 04:42:47 -0000 Received: (qmail 8684 invoked by alias); 18 Jun 2000 04:42:36 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11963 Received: (qmail 8668 invoked from network); 18 Jun 2000 04:42:34 -0000 From: "Bart Schaefer" Message-Id: <1000618044219.ZM12778@candle.brasslantern.com> Date: Sun, 18 Jun 2000 04:42:19 +0000 In-Reply-To: <200006130925.LAA29687@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: wish for a colored completion system" (Jun 13, 11:25am) References: <200006130925.LAA29687@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (5.0.0 30July97) To: Sven Wischnowsky , zsh-workers@sunsite.auc.dk Subject: Tags vs. groups, and ZLS_COLORS (Re: wish for a colored completion system) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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