From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1231 invoked from network); 11 Apr 2000 15:05:14 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 11 Apr 2000 15:05:14 -0000 Received: (qmail 29399 invoked by alias); 11 Apr 2000 15:05:01 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10656 Received: (qmail 29388 invoked from network); 11 Apr 2000 15:05:00 -0000 Date: Tue, 11 Apr 2000 17:04:55 +0200 (MET DST) Message-Id: <200004111504.RAA04918@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Tue, 11 Apr 2000 14:58:17 +0000 Subject: Re: PATCH: Re: 3.1.6-dev-22 Bart Schaefer wrote: > On Apr 11, 9:54am, Sven Wischnowsky wrote: > } Subject: PATCH: Re: 3.1.6-dev-22 > } > } I wrote: > } > } - The change to file-patterns suggested by Peter (I planned to send > } this in a separate patch and then accidentally overwrote it, sorry). > } I.e. it looks a bit more like tags-order, one can do: > } > } ... file-patterns '*.o:obj-files *(-/):dirs' ... > } > } Giving more than one pattern per string, with different tags. Small > } problem: one can still give more than one pattern per tag -- and has > } to separate them with commas. I don't like that, it's different from > } every other separation character we have. > > One possibility is to use the familiar brace expansion syntax: > > ... file-patterns '{*.(a|o),*(*)}:compiled-files *(-/):dirs' ... > > In fact, that syntax could be used everywhere that multiple glob patterns > are presently separated by spaces, which would e.g. make it clearer that > all the patterns in a PATTERNS:TAG form were associated with the TAG. > However, that's a much bigger change, and I don't know whether it makes > parsing a lot more difficult. Damn, I was thinking about that, too, yesterday and then forgot it again. I'll have a look... > That also "looks like" it should mean: > > ... file-patterns '*.(a|o):compiled-files *(*):compiled-files ...' ... > > which ought to be supported as equivalent if it isn't yet, that is, > mentioning a tag a second time in the same string should union rather > than replace the previous patterns for that tag. Of course it does that (I also mentioned it in one of my replies to Peter, I think). It does that more-or-less automatically, btw. Because of the same tag they end up in the same group. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de