From: Bart Schaefer <schaefer@brasslantern.com>
To: Zsh Users <zsh-users@zsh.org>
Subject: Re: Complete with *part* not part*
Date: Fri, 12 Feb 2016 11:14:07 -0800 [thread overview]
Message-ID: <160212111407.ZM14812@torch.brasslantern.com> (raw)
In-Reply-To: <CAKc7PVA16kg_RcTEgScuF52XSE2PVQGVPiPXMiycpECaEKi-VQ@mail.gmail.com>
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
the format
:completion:FUNCTION:COMPLETER:COMMAND:ARGUMENT:TAG
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
known.
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 ...
next prev parent reply other threads:[~2016-02-12 19:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-12 11:48 Sebastian Gniazdowski
2016-02-12 15:39 ` Mikael Magnusson
2016-02-12 16:01 ` Bart Schaefer
2016-02-12 16:11 ` Sebastian Gniazdowski
2016-02-12 17:16 ` Bart Schaefer
2016-02-12 17:29 ` Sebastian Gniazdowski
2016-02-12 19:14 ` Bart Schaefer [this message]
2016-02-12 17:19 ` Sebastian Gniazdowski
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=160212111407.ZM14812@torch.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=zsh-users@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).