From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18574 invoked from network); 15 Feb 2000 12:08:48 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 15 Feb 2000 12:08:48 -0000 Received: (qmail 6662 invoked by alias); 15 Feb 2000 12:08:43 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9744 Received: (qmail 6654 invoked from network); 15 Feb 2000 12:08:42 -0000 Date: Tue, 15 Feb 2000 13:08:40 +0100 (MET) Message-Id: <200002151208.NAA12625@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Andrej Borsenkow"'s message of Tue, 15 Feb 2000 13:39:17 +0300 Subject: RE: RFD: Zsh styles and OOP ... Andrej Borsenkow wrote: > > > This is certainly interesting. Unfortunately it's going to > > make the whole > > > thing even more complicated, both for implementation and use. > > Furthermore, > > > we really need this to be right in 3.1.7 --- I would be against > > rewriting > > > the configuration for completion yet again. > > > > You are not alone here... > > > > The only problem is, it will be more and more hard to change anything after > ZSH is released. Guess why I'm trying to be as active as possible in this discussion. > > I may also repeat my suggestion that we can put the context-finding > > code from _complete and _normal into a separate function. This could > > then be called at the very beginning (bindable commands, > > _main_complete). It would at least fill the context/command field of > > the context name. > > It is not a question of missing context bits. The problem is, these bits are > completely meaningless in some cases. Unless we want to use different > completers for different commands, it does not help to know, what command is > being completed. > > I just wish, that context names properly reflect there usage :-) Does this boil down to: if I don't care about the (possibly empty) value of a certain context field (we currently call them fields in the context names we have now, you may call them sub-contexts or whatever), I don't want to have to mention it in the pattern I give? If so, is it really that irritating to have to use `*' in some places. And, from the other side, what's the big difference between an empty and an non-existing field. I mean, ok, without reading the documentation a context like ':completion:::::' may look weird, but if you always think about the field-tuple this actually conveys some meaning, saying that the values for some fields (think of them as separate sub-contexts now) is not yet known or `there is nothing'. E.g., if the function-field is empty, this actually says something, namely that the completion system was called due to a key press, not from some function. Oh, and when I said that we can set up at least one more field at the beginning, this of course (automatically, given the way style lookup works) means that one can give different completers for different commands. Which may be useful. And this means that it would make sense to tell users about that field from the beginning. All in all (with the change suggested), there would be only one field -- the argument field -- that would always be empty in context names used by completers. And here this empty string doesn't tell us anything interesting. But letting it appear even then has the nice effect that context names always have the same length. Unless, of course, we want to change the context stuff completely. Really completely. Not even using simple strings for context names. But I need a lot more ideas and suggestions, possibly even syntax for definition and lookup before I can talk about that. Just saying that something isn't good and should be done differently isn't exactly helpful ;-) Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de