From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9070 invoked from network); 14 Feb 2009 18:19:51 -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; 14 Feb 2009 18:19:51 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 88111 invoked from network); 14 Feb 2009 18:19:42 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 14 Feb 2009 18:19:42 -0000 Received: (qmail 20169 invoked by alias); 14 Feb 2009 18:19:27 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13851 Received: (qmail 20154 invoked from network); 14 Feb 2009 18:19:26 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 14 Feb 2009 18:19:26 -0000 Received: from mail-ew0-f20.google.com (mail-ew0-f20.google.com [209.85.219.20]) by bifrost.dotsrc.org (Postfix) with ESMTP id 3E48680271F0 for ; Sat, 14 Feb 2009 19:19:23 +0100 (CET) Received: by ewy13 with SMTP id 13so1242255ewy.21 for ; Sat, 14 Feb 2009 10:19:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=2ocR/ud90ix3KEjoBCHoEhh4ZuLOq0yOfZEwT+qGHz8=; b=PZuz2ZTnRSNVvcYgHPvg4lQ6GMKeyrn5KiDDFl1yiHNyyZ1mEzDpFqsxfCWtzAuNDY cY4nJ6aYZGx3AVpRFfUqLuzil40yeLBec9TB7pdBc/wSe8nVuLynanBLlKSaXuKn/LsJ uM9z1XpS3KpdnkK54KNuCyZSa9P053njSerGs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=d70JHJLycuWxutbH7qFIOgrCOPOkA0yn6gBTI/agwX96wuOuSJ10qSelJUkhMpLZxZ 981ROlnYM8bm3ULnmUBVKhT1ZLj2gOJ+RBqybyPp0CE/8PSbTa2ifV/ZKW6SPOSJEMO9 WzUoQqnVmPw516D2zm/VCEHTvLdjtF9Sffuok= MIME-Version: 1.0 Received: by 10.210.136.10 with SMTP id j10mr2770987ebd.25.1234635562399; Sat, 14 Feb 2009 10:19:22 -0800 (PST) In-Reply-To: <200902141801.n1EI1E2l003603@pws-pc.ntlworld.com> References: <237967ef0902140622s7389d2c8h5a0c786dcf207422@mail.gmail.com> <200902141801.n1EI1E2l003603@pws-pc.ntlworld.com> Date: Sat, 14 Feb 2009 19:19:22 +0100 Message-ID: <237967ef0902141019t30118690m30116c9413015d96@mail.gmail.com> Subject: Re: Problem with fake-files style and cd From: Mikael Magnusson To: zsh-users Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92.1/8992/Sat Feb 14 16:43:07 2009 on bifrost X-Virus-Status: Clean 2009/2/14 Peter Stephenson : > Mikael Magnusson wrote: >> I want to complete foo/ in ~, and when I do this >> zstyle ':completion::complete:cd::' fake-files $HOME:foo >> I get the completion without the trailing /, if I do >> zstyle ':completion::complete:cd::' fake-files $HOME:foo/ >> I get a trailing slash _and_ a trailing space. Is there a bug or did I >> miss something obvious? When I don't get the slash I don't get a space >> either. > > It's not really a bug, no. fake-files isn't handled by _cd, it's > handled by _path_files, in other words it's a generic adder of fake > files; it has never tried to guess the context in which the file is > being added, nor is it documented to do so. So it can't know that when > you add a fake file "foo" it's a directory. Since it's a generic fake > *file*, there's nothing special about adding a slash, it just adds the > full match; and since it's a generic *fake* file it can't test what's > there to see how to handle it. (There's some support for things that > spring into existence when referenced; is that not the case here? If it > is this might be a bug but I'm not going to be able to look at it on my > system.) (No, I've modified the _cd completer a bit to only add $cdpath things if the first component is already typed out, because when I'm sitting in a dir with only one subdir and type cd i would like that directory completed and not the 50 ones in my cdpath. I used to have a ~/code symlink to point to where my code dir really is, and both ~ and that dir is in my $cdpath. This causes listings of this type though: % cd code/ ---- local directory zsh/ ---- directory in cdpath zsh/ and this was mostly a feeble attempt to get around that by removing the symlink and readding it as a fake directory.) > I can see it would be convenient to add special support for a "/" at the > end of fake files along the lines of your second attempt; however, there > is no simple, elegant, bug-free way of adding anything to _path_files > (you're lucky if you get one of the three). In this case I couldn't see > anything better than horribly ad-hoc tricks along the lines of "if you > get a single match at this point in the file and it's got a slash at the > end then remove the slash and add it again as a removable suffix". > It's probably doable, but horribly ad-hoc tricks usually don't fit into > any of the three categories above. > > Users are encouraged to look at _path_files for themselves as an > exercise. Thanks for the explanation, I gather that I can probably not make it work easily, so for now I think I'll just put the symlink back :). Actually, mkdir code does what I want... Of course, my real question should have been if I can make the completion listing remove duplicate entries when I have both a real directotry and an entry in cdpath that matches, but I guess if you have a real dir foo/bar and a cdpath dir foo/baz you want to be able to complete to foo/baz too. Maybe it doesn't have to show up as a cdpath entry at the foo point though, since the cd builtin won't actually go there anyway? -- Mikael Magnusson