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

[dana <dana@xxxxxxx>]

On Mon 25 May 2026, at 03:51, Mikael Magnusson wrote:
> I'm not sure if there's an obvious solution here, unfortunately. We
> could go through all the utility functions and at least use zparseopts
> instead of checking $1, but this will still stop working if _arguments
> ever wants to pass on more options to compadd and they collide with
> whatever options the utility functions use. I think the current set of
> options that can be added is (-J -X -V -F -x -M -n -2 -1) (documented
> under the entry for _guard for some reason), is this specified as
> being the only ones we will ever pass on like this? If all the utility
> functions used long options, this wouldn't be a problem, but obviously
> we already have many that use short options.

yeah i think anyone who tries to work on those functions quickly
realises this situation. the better written ones, like _numbers as you
mentioned, do avoid using those options for themselves, and pass them on

one idea i had a long time ago was for _main_complete or w/e to set an
array of zparseopts specs for all of those special options, which
utility/type functions could at least re-use instead of each one having
to hard-code them

that won't help much with the problem of adding new ones though

there are a few type functions i created/updated years ago that use long
options to try to avoid that but tbh i think it's really ugly and i wish
i hadn't done it

maybe we could do a survey of what options are currently in use by
utility/type functions and declare a few of the ones that aren't as
reserved

dana