From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11722 invoked from network); 2 Feb 2000 09:21:18 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 2 Feb 2000 09:21:18 -0000 Received: (qmail 17735 invoked by alias); 2 Feb 2000 09:21:11 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9525 Received: (qmail 17727 invoked from network); 2 Feb 2000 09:21:11 -0000 Date: Wed, 2 Feb 2000 10:21:09 +0100 (MET) Message-Id: <200002020921.KAA10135@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Peter Stephenson's message of Tue, 01 Feb 2000 18:45:30 +0000 Subject: Re: match again Peter Stephenson wrote: > It looks better, but is it enough to sort out all possible cases where you > might want to use `:*:'? Or are there even more cases where we might get > into trouble with that? I'm worried we could be barking up the wrong tree, > and should, for example, fix the fields of the pattern to > e.g. :completion:completer:command-or-context:arguments:tag (this may not > even be complete) with unrequired fields set to null strings but retaining > the colons, so you can always guarantee to pick out the appropriate > bit (unless there are extra colons inside the fields). This will mean a > lot of multiple colons, but I don't think that's a major problem (in fact, > that's where we're heading anyway). > > Any other uses of colons in the pattern --- e.g. to indicate a command name > --- would have to be rethought, but replacing the second `:' by a `-' might > be enough. Or just have commands and other contexts specified in different > fields (i.e. one is ...::command:... and the other ...:context::). > > Probably the big headache would be enforcing consistency in the code as it > stands --- virtually every use of styles would have to be rewritten. But > I like the idea that you can set `acontext=(${(s.:.)curcontext})' and pick > a particular word of $acontext to check. Yes, I'd like that, too -- and changing almost every function has been done before. I don't think that we would need to change that many functions anyway. The problem is with `nested' completions a la `cvs add ...' where it is very convenient to be able to stuff the `add' into the context name, but maybe `cvs-add' is just as good. And in cases like `find . -exec cvs add ' we probably don't need to have both `find' and `cvs' in the final context name. All this has been suggested before, btw (by Bart). He even suggested using an array. I'd prefer to still use a simple string to make testing and re-defining faster and cheaper, but if we don't use extra fields for the `nested' cases above, it would be nice to be able to access fields directly -- which suggests using a tied array at least in those functions that modify some fields (instead of just saving/restoring $curcontext or appending one of the basic name components). We may need another field: my suggested nslookup function sticks a `:nslookup' after the `:completion' -- but maybe we don't really need that. For things like the `cvs-add' above and the number of errors accepted by correct and approximate using another separation character might be a good idea... opinions? Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de