Zsh Mailing List Archive
Messages sorted by:
Re: Complete with *part* not part*
On Feb 12, 6:29pm, Sebastian Gniazdowski wrote:
} Fine thing the dtrace, huh. I think it reveals some bugs in my
} completion design. Should I be using -C for _arguments? Because there
} are tests that look bad, double "argument-rest":
} Zstyle -s :completion::complete:zplugin:argument-rest:argument-rest
} matcher match
No, nothing is wrong there. Remember that the lookup context is of
So you have COMMAND=zplugin, ARGUMENT=argument-rest, TAG=argument-rest,
which is entirely normal:
* The ARGUMENT; this indicates which command line or option argument
we are completing. For command arguments this generally takes the
form argument-N, where N is the number of the argument, and for
arguments to options the form option-OPT-N where N is the number
of the argument to option OPT. However, this is only the case if
the command line is parsed with standard UNIX-style options and
arguments, so many completions do not set this.
The doc omits the detail that N can be "rest" when all remaining argument
positions are treated the same.
* The TAG. As described previously, tags are used to discriminate
between the types of matches a completion function can generate in
a certain context.
So you only want -C if there are multiple tags in the argument-rest
context, *and* those tags are differentiated by using the ->state
form of _arguments specification.
The doc goes on:
The context is gradually put together as the functions are executed,
starting with the main entry point, which adds :completion: and the
FUNCTION element if necessary. The completer then adds the COMPLETER
element. The contextual completion adds the COMMAND and ARGUMENT
options. Finally, the TAG is added when the types of completion are
The tag name is actually generated by the "comparguments" builtin in this
case, which was intentionally left under-specified in the user-level doc,
but then developer-level doc for it was never written ...
Messages sorted by: