From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29504 invoked from network); 10 Mar 2009 18:06:46 -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; 10 Mar 2009 18:06:46 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 2879 invoked from network); 10 Mar 2009 18:05:08 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 10 Mar 2009 18:05:08 -0000 Received: (qmail 27471 invoked by alias); 10 Mar 2009 18:05:02 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26710 Received: (qmail 27450 invoked from network); 10 Mar 2009 18:05:01 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 10 Mar 2009 18:05:01 -0000 Received: from mail-ew0-f172.google.com (mail-ew0-f172.google.com [209.85.219.172]) by bifrost.dotsrc.org (Postfix) with ESMTP id 586C380307F8 for ; Tue, 10 Mar 2009 19:04:57 +0100 (CET) Received: by ewy20 with SMTP id 20so1329551ewy.45 for ; Tue, 10 Mar 2009 11:04:57 -0700 (PDT) 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=3o2Rp+/tGPg0wz1Ukz72dpvGYuUWNDsc+xCOS8+UQ4g=; b=UVy8VzDgsydh2YDZl00y5tsVyCwaT9sLtL8jf2FfJZbdDXOXyU98oSVyUHWRkRDQu+ JYk8oBGSYjeYtCQ+cGzrf2Yj2KnQFWXHgIhzAkAIiW8ZYgwcuLO27StXkqtFjOz1OJE/ anDiUsCjpQ5EGqZa6t+Bn+uwIPCOK/CFwroUE= 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=pBoYfLiYi/VJvxqVWGJGBLfsQMBsifDN0Is/2NPgsVju3VyViAryMF3XlzK/HtkNl0 icn6wiw6yPkVmXSZa/2R3tij55iLwUSKEfyLpt5VwKAL+Lm1QJrLTvXxwuVKk3jUUIC5 M25OFYJTnOdR7gaA6tjrq6esVH/BEnTZChxhg= MIME-Version: 1.0 Received: by 10.210.71.12 with SMTP id t12mr4743739eba.95.1236708295010; Tue, 10 Mar 2009 11:04:55 -0700 (PDT) In-Reply-To: <20090310173424.1af302c5@news01> References: <237967ef0903100625s7e8e5908t7852ade0c1d6d8d3@mail.gmail.com> <20090310135146.30c0c794@news01> <20090310173424.1af302c5@news01> Date: Tue, 10 Mar 2009 19:04:54 +0100 Message-ID: <237967ef0903101104y135e0ca6sdbd9fbe8272f2d99@mail.gmail.com> Subject: Re: setopt globcomplete and () broken From: Mikael Magnusson To: zsh-workers Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92.1/9084/Tue Mar 10 08:11:13 2009 on bifrost X-Virus-Status: Clean 2009/3/10 Peter Stephenson : > On Tue, 10 Mar 2009 13:51:46 +0000 > Peter Stephenson wrote: >> elif [[ "$tmp1" = (#b)(*[^\$])(\(\([^\|~]##\)\)) ]]; then >> tmp2=( "$tmp2[@]" "${match[1]}((${tmp3}${match[2][3,-1]}" ) > > I thought I was on the way to understanding what was going on here, but > this attempt to match some form of glob qualifiers has stumped me. Why are > we specially matching a pattern ending with glob qualifiers wrapped in > double parentheses? What we're matching against, $tmp1, comes from patterns > supplied to _files or _path_files as an argument; I can't see any sign the > double parentheses are used, and the expansion manual says > > A glob subexpression that would normally be taken as glob qualifiers, for > example (^x), can be forced to be treated as part of the glob pattern by > doubling the parentheses, in this case producing ((^x)). > > Yet we are treating it as if it's a glob expression ($tmp3 is the > new glob qualifier we are trying to insinuate into the list). > > Can I simply hold my breath until it goes away? If I delete that whole paragraph of code, my completion works as I want, but I break what it wanted to fix, http://www.zsh.org/mla/workers/2000/msg02437.html http://www.zsh.org/mla/workers/2000/msg02455.html http://www.zsh.org/mla/workers/2000/msg02456.html http://www.zsh.org/mla/workers/2000/msg02458.html If I unsetopt globcomplete, I can ls *zshenv(D) with the paragraph deleted though, so it all seems a bit crazy to me. I thought globcomplete was about completing things with patterns that weren't files in the first place, so why do glob qualifiers come into the picture at all? ie what I want to do is *2png and find my ps2png program, I don't see how (D) would ever fit in there. I guess some crazy people might have binaries starting with a ., but apart from the sorting flags, none of the other glob qualifiers make any sense here, do they? And when completing actual files, why would globcomplete mean _path_files has to do extra work instead of just expanding the pattern? Put differently, why does globcomplete affect _path_files at all? Hm, if i touch cat cbt, then with globcomplete on, c*t lets me cycle between them, while with it off, it just inserts both matches. (this is with zstyle ':completion:*' completer _oldlist _complete _correct ) In summary, I guess I have no idea how any of this works :). -- Mikael Magnusson