zsh-users
 help / color / mirror / code / Atom feed
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 ...


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