From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2629 invoked from network); 14 Jan 2002 17:02:11 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 14 Jan 2002 17:02:11 -0000 Received: (qmail 25530 invoked by alias); 14 Jan 2002 17:02:05 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16452 Received: (qmail 25508 invoked from network); 14 Jan 2002 17:02:05 -0000 To: zsh-workers@sunsite.dk (Zsh hackers list) Subject: Re: PATCH: updated _zstyle and cleanup of related stuff In-reply-to: ""Bart Schaefer""'s message of "Mon, 14 Jan 2002 16:36:55 GMT." <1020114163655.ZM18433@candle.brasslantern.com> Date: Mon, 14 Jan 2002 17:01:37 +0000 Message-ID: <6404.1011027697@csr.com> From: Peter Stephenson "Bart Schaefer" wrote: > On Jan 14, 1:57pm, Peter Stephenson wrote: > } Subject: Re: PATCH: updated _zstyle and cleanup of related stuff > } > } Oliver wrote: > } > I wish multiple glob qualifiers in series (e.g. *(@)(u0)) were allowed > > There's also the minor issue of how you know whether to logical-and or > logical-or the flags together. If you want logical-or, you still have > to parse for the parens and stuff in the comma and new flags. I don't see how that would work, anyway. You've got to define the separate parentheses as being related in one fashion or the other, and `and' is the obvious one. (It probably needs more work to get commas completely consistent as it is, I didn't examine that factor.) > Please let's not have arbitrary appending of glob quals until they are not > BARE any more. That's another thing we've been ducking. In ksh-compatibility mode we can just grab another character, such as `-' or `_' or `,' or `:'. I can't see any simple, friendly zsh-like way of doing it, though. About the only backwardly compatible way I can think of is restrict it to EXTENDED_GLOB and use something like `(#q.)'. The good news there is that we can make the pattern code ignore it --- so `*(#q.)' will match any normal file for globbing, anything at all for other forms of pattern matching. The other good news is this would start working straight away in the completion code, since EXTENDED_GLOB is always on. The other question is whether you still require them to be at the end of the pattern, which is convenient for parsing but less justifiable as a restriction on the syntax. I hate having to trawl through expressions for parentheses. -- Peter Stephenson Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 392070 ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. **********************************************************************