Justin Garrison wrote:
> I have a custom completion script I'm working on that has a few different
> functions used for completion (I'm modifying existing completion scripts so I
> can't change some of them)
>
> __start_k -> calls __k_handle_word -> calls __k_handle_kspace -> calls
> __k_kspace_parse_config
Lots of nested functions is fairly common and is unlikely to be the
source of problems unless you forget to declare variables local. You
seem to have a number of variables that perhaps ought to be local such
as cur.
> I can see it being run if I set -x in that function (I'm echoing the array at
> the end of the compadd command and also tried with -a array_name)
Rather than use set -x, I'd recommend using the _complete_debug widget.
By default, pressing Ctrl-X followed by ? where you'd normally press
tab will invoke that. Then use up-history to retrieve the file with
the dumped trace information and if you use less as your pager, the &
command to filter it is very useful.
> +__k_kspace_parse_config:33> compadd -X CONTEXTS -P + -S '' bottlerocket
In itself, that compadd command looks fine. The -P option here adds a +
prefix at the beginning of the current word while your tests of
$words[CURRENT-1] look at the previous.
The functions are quite hard to follow with all the bash stuff in there.
The setopts in __k_bash_source() would break things if you've contrived
for them to apply within the zsh completion but I doubt that's the case.
Just to rule other problems sources out, I'd suggest renaming your
commands array so that it doesn't clash with the builtin variable from
zsh/parameters.
> $: k +
> -- no matches found --
>
> but this returns no matches even though the k_out array has values.
Where is the cursor, directly after the + or in the following (empty)
word?
Unlike bash. zsh "matches" the completion candidates against what is
already on the command-line so "no matches found" can mean that
candidates were added but none matched. Matching is done against $PREFIX
and $SUFFIX with any extra characters allowed in between (where the
cursor is). The assignment to PREFIX in __k_handle_reply() if it is
called may cause issues. It is common to move characters from the start
of $PREFIX to the end of $IPREFIX, usually by calling compset -P to do
that job. For debug, it can be helpful to dump the contents of those
variables to a separate tty before calls to compadd.
I'd suggest you simplify your test cases somewhat by replacing some
complex functions with very simple ones that just do something like
compadd one two three. Or perhaps copy the exact compadd that you see in
the trace output.
Without kubectl (and k) installed, I don't even get as far as the
failure you describe when trying out your function. It is irrelevant to
this but k doesn't seem like a great idea for naming. Single letters are
common choices for people's own aliases.
Oliver