Zsh Mailing List Archive
Messages sorted by:
Re: PATCH: tags
- X-seq: zsh-workers 8641
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: PATCH: tags
- Date: Mon, 15 Nov 1999 12:56:06 +0100 (MET)
- In-reply-to: "Bart Schaefer"'s message of Sun, 14 Nov 1999 18:30:04 +0000
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
Bart Schaefer wrote:
> } The <pat>s say for which context(s)
> } the styles given after them should be used. They are compared with
> } strings of the form: `<cmd>,<context>,<tag>'. <cmd> is the command
> } name (or one of the `-contexts-'), <context> is the sub-context and
> } <tag> 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.)
> 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
> (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.
Sven Wischnowsky wischnow@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by: