Re: PATCH: tags

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

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.)

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@xxxxxxxxxxxxxxxxxxxxxxx