From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19692 invoked from network); 6 Sep 1999 14:08:57 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 6 Sep 1999 14:08:57 -0000 Received: (qmail 16434 invoked by alias); 6 Sep 1999 14:08:45 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7668 Received: (qmail 16427 invoked from network); 6 Sep 1999 14:08:44 -0000 Message-Id: <199909061408.QAA353048@hydra.ifh.de> X-Authentication-Warning: hydra.ifh.de: pws owned process doing -bs To: zsh-workers@sunsite.auc.dk (Zsh hackers list) Subject: Re: strange glob expansion In-reply-to: "Sven Wischnowsky"'s message of "Mon, 06 Sep 1999 14:43:23 MET DST." <199909061243.OAA02544@beta.informatik.hu-berlin.de> Date: Mon, 06 Sep 1999 16:08:39 +0200 From: Peter Stephenson Sven Wischnowsky wrote: > Peter Stephenson wrote: > > > By the way, does anyone want a globbing flag to turn on extended glob? > > e.g. (#x)foo and (#X)foo would compile pattern foo with extended glob > > on or off. > > That would then be an exception in that it is recognised even if > extendedglob is not set, right? Yes, that's ugly. There's no real reason why you'd use parentheses without extendedglob for such a pattern, but the special case is not nice. > Hm, dunno. May make things hard to read if you are used to using > extendedglob, I think. Although it sounds like something that may be > useful, although I can't come up with an example. I was thinking of the command line for people who don't usually use extendedglob, but that's probably not a very likely usage. Setting extendedglob locally in functions is certainly to be preferred, although sometimes you want to keep the user's setting while having your own extendedglob patterns (as in completion). > We had this discussion about allowing back-references. Personally I > don't think that just storing the matched portions in some special > array is the best way -- what if I'm really interested in the indexes > (beginning/end of matched part)? > > So how about a set of globbing flags that turn on collecting > back-references, say what information we want and give the name of an > array where that information is stored? Something like `(#mparts)...' > to store the matched parts in an array named `parts', `(#pbegs:ends)...' > to store the begin-positions in an array `begs' and the end-positions > in an array `ends'. Or something like that. Hmm, I was hoping to keep the globbing flag syntax compact and easy to read. We could have the array names fixed, to $match, $beginning and $end for example, but use the letters (#mbe) to decide which would be set, maybe also (#MBE) for setting MATCH etc. to the whole matched string for use in substrings. The arrays wouldn't have to be special, though, so you could make them local. This sort of arrangement (although using functions) seems to work OK in emacs. Can you think of examples where using the same variable names for different matches would cause a problem? For substitutions in ${.../../..${match[1]}..} this would mean delaying singsub() of the replacement string, and with global substitution re-substituting the replacement string on each loop. I think that's OK, although it could make quite a difference when substituting on arrays. That was one advantage of using some special syntax like \1 for backreferences: it's easy to detect when they're being used. > I don't know enough about the matching code to know if this `turn-on- > back-references-only-when-needed' is possible and easy enough to > implement and if the effect on the normal, non-collecting processing > is small enough (in terms of execution speed). There is some overhead with backreferences active --- each `(' and `)' uses another subroutine call --- but the speed overhead is essentially nil when not using backreferencing --- the fact that the size of the struct changes when using backreferences can be avoided, too; that was inherited from the Specner code, but in our case we don't need to store the extracted matches inside the struct. It looks like I can even do it with the normal grouping effect of globbing flags, i.e. you can turn it on and off in the middle, still with no significant overhead (so if you're not using it, the only difference is the odd extra test for the flags and zeroing things). I suppose it's potentially worth having backreferencing even with file globs for use with the e glob qualifier. That means retaining the number of the parenthesis over the entire filename path. By the way, I'm not planning on removing the limit of 9 backreferences. I think that ought to be sufficient. -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56100 Pisa, Italy