Re: PATCH: tags

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Nov 12,  3:55pm, Sven Wischnowsky wrote:
} Subject: PATCH: tags
}
} To use styles, `compinit' contains the function `compstyle'. without
} arguments it lists the current settings, with arguments they have to
} look like:
} 
}   _style <pat1> -style1 -style2 ... <pat2> -style3 ...
    ^^^^^^
(I presume that's supposed to say `compstyle'.  `_style' is for testing
the style at completion time, right?)

} I.e. here the styles begin with a hyphen (to make the easily
} distinguishable form the <pat>s).

What happens if the pattern begins with a hyphen, as in the example where
the pattern is to be compared to one of the `-context-' forms, or for the
`-' precommand modifier?  I don't see how putting hyphens in front of the
styles helps any.  In fact, it might make more sense to put a character
in front of each pattern!

} 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='.

Can you give a slightly longer explanation of what exactly has changed
about using "->state" actions with _arguments etc.?

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

(We should try to come up with a better word than "tag" to describe what
these names represent.  Hmm.)

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

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com