compadd not returning completion options

compadd not returning completion options

[Justin Garrison]

[-- Attachment #1: Type: text/plain, Size: 1347 bytes --]

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

The __k_kspace_parse_config is where I run compadd for my completions

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)

+__k_kspace_parse_config:33> compadd -X CONTEXTS -P + -S '' bottlerocket
dev.demo.jgarr.net rothgar@alb-v2-ec2.us-west-2.eksctl.io
rothgar@fargate.us-west-2.eksctl.io rothgar@prod.us-west-2.eksctl.io
rothgar@stage.us-west-2

$: k +
 -- no matches found --

but this returns no matches even though the k_out array has values.

If I run

compdef __k_handle_kspace k

everything works as expected. I'm not sure why it matters which function I
use when the function that sets the completion values is still the same.

I have some more links to the code and information here in stackoverflow
but haven't been able to figure out why this is happening.
https://stackoverflow.com/questions/64150319/compadd-doesnt-work-when-called-from-nested-functions

Any pointers or help on what I could be doing wrong are appreciated.


--
Justin Garrison
justingarrison.com

[-- Attachment #2: Type: text/html, Size: 3489 bytes --]

Re: compadd not returning completion options

[Oliver Kiddle]

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

Re: compadd not returning completion options

[Justin Garrison]

[-- Attachment #1: Type: text/plain, Size: 4326 bytes --]

Thank you so much for taking the time to reply. I wish I had known about
__complete_debug widget before. When I used it I quickly noticed that after
my completion runs (and adds the completions I want) _bash_complete runs
which calls

+_default:5> zstyle -s :completion::complete:k:: use-compctl ctl

which then proceeds to try and match files starting with my special
characters (easily confirmed by creating some dummy files starting with
those characters)

+_path_files:467> tmp1=( completions foo _foo go.mod go.sum LICENSE main.go
main_test.go Makefile README.md )
...
+_path_files:516> compadd -D tmp1 -M 'r:|[._-]=* r:|=* l:|=*' -a tmp1

There's a whole lot more it does that I'm not sure where it comes from and
finally I see

+_main_complete:357> zformat -f mesg ' %F{red}-- no matches found --%f'
'd:`file''' D:file


+_main_complete:358> compadd -x ' %F{red}-- no matches found --%f'

So I think if I can figure out how to make + @ and : not complete filenames
I might be set.
Looking through all the commands and flags that are generated by kubectl
completion I'm sure it's possible but I'll need to figure it out.

Thank you for the help and pointing in me in the right direction.

--
Justin Garrison
justingarrison.com


On Fri, Oct 2, 2020 at 9:26 AM Oliver Kiddle <opk@zsh.org> wrote:

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

[-- Attachment #2: Type: text/html, Size: 6871 bytes --]