From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1583 invoked from network); 28 May 2001 15:55:43 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 28 May 2001 15:55:43 -0000 Received: (qmail 1241 invoked by alias); 28 May 2001 15:55:35 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14509 Received: (qmail 1180 invoked from network); 28 May 2001 15:55:33 -0000 Date: Mon, 28 May 2001 11:55:30 -0400 From: Clint Adams To: zsh-workers@sunsite.dk Cc: 98424-forwarded@bugs.debian.org, mdz@debian.org Subject: PATCH: ZLS_COLORS/ZLS_COLOURS consistency in _setup Message-ID: <20010528115530.A17073@dman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i This attempts to follow the course of action outlined as option #1 in the message included after the patch, though I agree that clobbering those parameters is counterintuitive. I wonder why ZLS_COLORS and ZLS_COLOURS aren't linked together as special parameters by zsh/complist. I also think the precedence of those two should be documented. Index: Completion/Base/Core/_setup =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/Base/Core/_setup,v retrieving revision 1.1 diff -u -r1.1 _setup --- Completion/Base/Core/_setup 2001/04/02 11:04:32 1.1 +++ Completion/Base/Core/_setup 2001/05/28 15:42:33 @@ -20,7 +20,7 @@ # ZLS_COLORS="$ZLS_COLORS$ZLS_COLOURS" elif [[ "$1" = default ]]; then - unset ZLS_COLORS + unset ZLS_COLORS ZLS_COLOURS 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.124 diff -u -r1.124 compsys.yo --- Doc/Zsh/compsys.yo 2001/05/09 08:55:59 1.124 +++ Doc/Zsh/compsys.yo 2001/05/28 15:42:36 @@ -1483,7 +1483,7 @@ item(tt(list-colors))( If the tt(zsh/complist) module is used, this style can be used to set color specifications as with the tt(ZLS_COLORS) and tt(ZLS_COLOURS) -parameters (see +parameters, which will not be honored under this completion system (see ifzman(the section `The zsh/complist Module' in zmanref(zshmodules))\ ifnzman(noderef(The zsh/complist Module))\ ). Index: Doc/Zsh/mod_complist.yo =================================================================== RCS file: /cvsroot/zsh/zsh/Doc/Zsh/mod_complist.yo,v retrieving revision 1.14 diff -u -r1.14 mod_complist.yo --- Doc/Zsh/mod_complist.yo 2000/10/05 08:41:37 1.14 +++ Doc/Zsh/mod_complist.yo 2001/05/28 15:42:36 @@ -127,7 +127,7 @@ `tt($colors[red])' to get the code for foreground color red and `tt($colors[bg-green])' for the code for background color green. -If the completion system based around shell functions is used, these +If the completion system invoked by compinit is used, these parameters should not be set directly because the system controls them itself. Instead, the tt(list-colors) style should be used (see ifzman(the section `Completion System Configuration' in zmanref(zshcompsys))\ ----- Forwarded message from Matt Zimmerman ----- > In that case, do you get the same behavior with zsh -f ? > What's causing the zsh/complist module to be loaded? > Is it direct, or is it due to a zstyle setting? The problem seems to have to do with when compinit is loaded. For example, when I do this: mizar:[~] env -i zsh -f mizar% export TERM=xterm mizar% eval `dircolors -b` mizar% export ZLS_COLORS="$LS_COLORS" mizar% zmodload zsh/complist mizar% cd [TAB] I get a colored completion listing. However, if I load compinit (mimicking what happens in my .zlogin): mizar:[~] env -i zsh -f mizar% export TERM=xterm mizar% eval `dircolors -b` mizar% export ZLS_COLORS="$LS_COLORS" mizar% zmodload zsh/complist mizar% autoload -U compinit mizar% compinit mizar% cd [TAB] the listing is not colored. However, if I use the ZLS_COLOURS variable instead: mizar:[~] env -i zsh -f mizar% export TERM=xterm mizar% eval `dircolors -b` mizar% export ZLS_COLOURS="$LS_COLORS" mizar% zmodload zsh/complist mizar% autoload -U compinit;compinit mizar% cd [TAB] the listing is colored. This is what prompted me to file this bug report originally. Even if I set the variable after compinit is loaded: mizar:[~] env -i zsh -f mizar% export TERM=xterm mizar% eval `dircolors -b` mizar% zmodload zsh/complist mizar% autoload -U compinit;compinit mizar% export ZLS_COLORS="$LS_COLORS" I get no colors. However, I now notice this comment at the bottom of the complist section is zshmodules(1): If the completion system based around shell functions is used, these parameters should not be set directly because the system controls them itself. Instead, the list-colors style should be used (see the section `Completion System Configuration' in zshcompsys(1)). I didn't notice this section because it refers to "the completion system based around shell functions", which didn't make me think of the new completion system. Maybe it should be clarified. So, it looks like neither _COLORS or _COLOURS should work when using compinit, but _COLOURS still does. That is a software bug. There is another documentation bug: what prompted me to set these variables originally was this passage in zshcompsys(1): list-colors If the zsh/complist module is used, this style can be used to set color specifications as with the ZLS_COLORS and ZLS_COLOURS parameters (see the sec­ tion `The zsh/complist Module' in zshmodules(1)). This section should make it clear that ZLS_* should _not_ be used, and will be ignored. As it is, it implies that they will still be honored. In summary: - Either: 1. Both ZLS_COLOURS and ZLS_COLORS should be ignored when compinit is loaded, not just ZLS_COLORS 2. Both variables should be used (I find this behavior more intuitive) - If 1., zshcompsys(1) should mention that these variables will be ignored - If 1., zshmodules(1) should be clarified to say which completion system it is talking about (perhaps using wording like "the completion system described in zshcompsys(1)", if there is no proper name for it) ----- End forwarded message -----