Re: completion utility functions that take options generally do not work

Passing compadd options on to utility and helper functions to the
extent that we do it likely wasn't envisioned as part of the original
design. Early functions like _values, _describe, _alternative and
_arguments don't particularly handle them, or where they do, only as an
after-thought. _dir_list is also old and gets limited use. With shell
functions, recursive-descent style parsing of the line is simple and
natural but leads to this situation of compadd options being accumulated
along with nested tag/label loops. Only a single tag loop as you tend to
get with _arguments or _regex_arguments is tidier and works better with
tag-order styles.

But in the position we now are, it is better to avoid clashing with
compadd options on new functions. But there isn't a definitive list of
compadd options that need to be avoided because it can depend. The list
you give for _guard is likely only applicable to that function. -f/-W
and -e are sometimes applicable, sometimes not. For -p and -s as well as
-A, -D and -O, and maybe -M, it largely depends on whether the function
splits things up with compset. Some like -a, -k, -d, -l, -C and -E are
fairly much always fair to overload. In some cases, the compadd options
may be newer than the utility function; only -o is especially new. I'd
have considered -n harmless enough with _numbers because it mostly
doesn't add matches but probably didn't consider the hidden style. In
the case of _sequence, you're often better to have _sequence on the
outside, wrapping _wanted, than the other way around which would allow
the hidden style to be specified without affecting it.

The options are also not the same in terms of how they should be
handled when accumulated. Do you want the caller to override your local
descriptions? For matching control, the order matters (especially with
x:) but is often wrong. When breaking up a word with compset -S, -q,
-r and -R apply only to the last part while -P only applies to the
first part. And for -p/-s/-i/-I you'd probably have to be combining all
the parts together but that's far too complex for anyone to have ever
bothered.

You called out _numbers, _sequence and _email_addresses, all of
which are relatively new and contributed by me. So perhaps not a
representative sample to draw conclusions from. It could be worthwhile
to try to improve some of the helpers that do a less good job and
perhaps create an abstraction around the common zparseopts used. Not
sure we can really change them where "forbidden" ones are used because
of backward-compatibility.

Oliver