From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1526 invoked from network); 4 Aug 2008 00:34:24 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 4 Aug 2008 00:34:24 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 68867 invoked from network); 4 Aug 2008 00:34:10 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 4 Aug 2008 00:34:10 -0000 Received: (qmail 28943 invoked by alias); 4 Aug 2008 00:33:50 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25381 Received: (qmail 28918 invoked from network); 4 Aug 2008 00:33:46 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 4 Aug 2008 00:33:46 -0000 Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by bifrost.dotsrc.org (Postfix) with ESMTP id 459B880590E6 for ; Mon, 4 Aug 2008 02:33:37 +0200 (CEST) Received: from torch.brasslantern.com ([96.238.220.175]) by vms173001.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0K5100AC3W7NV8X1@vms173001.mailsrvcs.net> for zsh-workers@sunsite.dk; Sun, 03 Aug 2008 19:33:24 -0500 (CDT) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id m740XMr0031529 for ; Sun, 03 Aug 2008 17:33:23 -0700 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id m740XLBP031528 for zsh-workers@sunsite.dk; Sun, 03 Aug 2008 17:33:21 -0700 Date: Sun, 03 Aug 2008 17:33:21 -0700 From: Bart Schaefer Subject: Re: completion: highlight matching part In-reply-to: <080803103117.ZM26039@torch.brasslantern.com> To: zsh-workers@sunsite.dk Message-id: <080803173321.ZM31527@torch.brasslantern.com> MIME-version: 1.0 X-Mailer: OpenZMail Classic (0.9.2 24April2005) Content-type: text/plain; charset=us-ascii References: <20080801163301.GA3589@pepin.polanet.pl> <080802143558.ZM815@torch.brasslantern.com> <20080803111423.GA11247@pepin.polanet.pl> <080803103117.ZM26039@torch.brasslantern.com> Comments: In reply to Bart Schaefer "Re: completion: highlight matching part" (Aug 3, 10:31am) X-Virus-Scanned: ClamAV 0.92.1/7929/Mon Aug 4 01:08:55 2008 on bifrost X-Virus-Status: Clean [> workers] On Aug 3, 10:31am, Bart Schaefer wrote: } Subject: Re: completion: highlight matching part } } The complist module installs some defaults if $LS_COLORS is empty. The } problem is that the form beginning with an equal or a star is supposed } to take precedence over those defaults, but it does not. Instead (if } I'm reading the code correctly) it takes precedence only over explicit } settings of all the possible $LS_COLORS colorings. I've tracked this (by a much more roundabout route than necessary) to PWS's patch 25006, in which he asserts (for compatibility with GNU ls) that "File type tests from stat should come before extension tests." The documentation still says that extension tests win and file type tests come last, so this should have been changed at the same time that complist.c was modified. But clearly in this instance we want pattern tests to take precedence over file type tests. I don't think there's any equivalent in GNU ls to this particular zsh-ism, so we have several choices: (1) Change complist.c:putfilecol() so that pattern tests come first, then mode tests, and finally extension tests. (2) Do something convoluted where we check for an extension match, but if we find one, try the mode tests before returning the extension color. We end up with a sort of rock-paper-scissors behavior, where modes beat extensions beat patterns beat modes. (3) Simply update the doc and make it impossible to do what Tomasz originally asked for, except in old versions of the shell that are not GNU ls compatible. (4) Revert to the pre-25006 behavior. Obviously the doc needs updating no matter what (in case 4, to point out that we're not compatible with ls). I have the impression that prior to this discussion the backref-using patterns for completion coloring were not particularly widespread, so it probably won't cause any major upheaval whichever way we go.