zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <opk@zsh.org>
To: Justin Garrison <justinleegarrison@gmail.com>
Cc: zsh-workers@zsh.org
Subject: Re: compadd not returning completion options
Date: Fri, 02 Oct 2020 18:26:06 +0200	[thread overview]
Message-ID: <72371-1601655966.237415@B17K.ueth.p0Xz> (raw)
In-Reply-To: <CANS=CAffsA9xunCBL1G-K_EVR+7bH_ttFxg3A_+Ob5Lzx0od2g@mail.gmail.com>

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


  reply	other threads:[~2020-10-02 16:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-01 23:53 Justin Garrison
2020-10-02 16:26 ` Oliver Kiddle [this message]
2020-10-03  8:15   ` Justin Garrison

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=72371-1601655966.237415@B17K.ueth.p0Xz \
    --to=opk@zsh.org \
    --cc=justinleegarrison@gmail.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).