From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27875 invoked from network); 15 Nov 1999 11:56:24 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 15 Nov 1999 11:56:24 -0000 Received: (qmail 20038 invoked by alias); 15 Nov 1999 11:56:18 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8641 Received: (qmail 20031 invoked from network); 15 Nov 1999 11:56:17 -0000 Date: Mon, 15 Nov 1999 12:56:06 +0100 (MET) Message-Id: <199911151156.MAA31853@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Sun, 14 Nov 1999 18:30:04 +0000 Subject: Re: PATCH: tags Bart Schaefer wrote: > ... > > } The s say for which context(s) > } the styles given after them should be used. They are compared with > } strings of the form: `,,'. is the command > } name (or one of the `-contexts-'), is the sub-context and > } is the tag name. > [...] > } For example, `_arguments' uses context names like `-option-n' and > } `argument-n' where the `n' gives the number of the argument. > > Clarification: In the description above, `-option' is a reference to the > actual command-line option (e.g., `-f-2' is the context of the second > argument following `-f') whereas `argument' is a verbatim string. (Just > to be sure I understand correctly.) Yes. > I'm not sure what the context would be for whatever comes directly after > the equal sign in the same word as an option, e.g. of the form `--file='. In this case `-file-1'. We could change that to, e.g. `-file=1', but the `-file=' option definition is only a special case of `-file+' nowadays. I.e. `_arguments' can also accept the argument in a separate word on the line. That's because Tanaka pointed out that the GNU-getopts accepts long options this way. > Can you give a slightly longer explanation of what exactly has changed > about using "->state" actions with _arguments etc.? This is now described extensively (well, what I call extensively) in the `Etc/completion-style-guide'. If you read it you'll see that I found a way to make that quite use-friendly (I hope you'll agree) with the `-C' option. > } Also, I don't have docs for the tags and styles used yet. For the tags > } I'm still wondering how we are to document them -- some kind of list I > } guess, but we probably also say which functions use them. And that > } would require naming lots of functions that are otherwise not > } mentioned in the docs. A bit ugly I think. > > For now I'd say forget listing the functions that use them ... pick some > tag names, be sure they're used consistently by the functions we provide, > and recommend that users' new functions use the same ones whenever it > makes sense. Then just document the tag names we use. Yes, I will do that when we decided on my other documentation suggestions. Then I will also check if I've used the tag names consistently. > (We should try to come up with a better word than "tag" to describe what > these names represent. Hmm.) I was playing with the name `types' from the beginning (and I still sometimes say `types of matches'). Dunno. > } Misc. remarks: > } - There may be a better name than `_sort_tags'. Also, we could give > } the return value of this function some meaning. I don't know which, > } though. > > The better name than "_sort_tags" will arise from having a better name > than "tags", I expect. Hopefully. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de