Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: git-subtree completions
- X-seq: zsh-users 21560
- From: Oliver Kiddle <okiddle@xxxxxxxxxxx>
- To: Jordan Klassen <jordan@xxxxxxxxxxxxx>
- Subject: Re: git-subtree completions
- Date: Fri, 13 May 2016 14:02:38 +0200
- Cc: zsh-users@xxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1463140959; bh=COwIwKHCCuYBtLrmM4L4HKcheZoy3R380hX7jgoOyko=; h=cc:In-reply-to:From:References:To:Subject:Date:From:Subject; b=YvxKjMoea8O6CQJcw46nCaLAcclU1DJ4HKtOMx8UtLc/eC96oB1om3dLMUtgWOy8+igTnx1j58smnMrnMB1c1Bsiw59dnI+t3Gx/jWk8NmAWZAjpNSrm66KBXTm5muftV4zv920IPHBz6KcvQlsFCI8W7xprw/ul6oPFN2l7q4rT+EZwhPIpZdP5ICwENphwB4BLkYAjCxuGy/cUX2+3ME+EoAgPYJzlVcQdCn2kFngqdWXHgEzCTria20RgSQsJvxdFt2JqoyJ4/Ea3vOnfjbeeKxmyOi6Tl5i7lMWMUeeXiwXVMOmQSr7Hg6zxQiGo+lolkRLXkVB7YVz5OG9rTg==
- In-reply-to: <CAEsdBDkYMG6fopG9uAxXPZuDoOu5iW1QBBwM1r1-BCZ-iEtEpw@mail.gmail.com>
- List-help: <mailto:zsh-users-help@zsh.org>
- List-id: Zsh Users List <zsh-users.zsh.org>
- List-post: <mailto:zsh-users@zsh.org>
- Mailing-list: contact zsh-users-help@xxxxxxx; run by ezmlm
- References: <CAEsdBDkYMG6fopG9uAxXPZuDoOu5iW1QBBwM1r1-BCZ-iEtEpw@mail.gmail.com>
Jordan Klassen wrote:
> How do I fix my `THIS_IS_A_HACK` issue?
Use -A "-*" and change this line:
'*:: :->option-or-argument' && ret=0
to:
'*::: := ->option-or-argument' && ret=0
> And code review in general.
Otherwise, it looks good. I'd suggest using _default instead of _nothing
for an unknown subcommand. _nothing might be more accurate at the moment
but falling back to default completion is better if a new subcommand is
added to git-subtree and the completion isn't updated. I'm aware that
the same comment could apply elsewhere in _git.
The descriptions for subcommands also could do with adjusting.
References to things like <commit> and <repository> make less sense in
the absense of the rest of the help information these have been copied
from.
Coming back to the THIS_IS_A_HACK issue, I think there is arguably a bug
in _arguments. The documentation states that with two
colons, "the words special array and the CURRENT special parameter are
modified to refer only to the normal arguments". I would expect the
command to be a "normal argument" in this context but -P coming after it
appears to affect this.
For: git subtree add <tab> we get words=( add '' ) CURRENT=2
For: git subtree add -P <tab> we get words=( '' ) CURRENT=1
_arguments in the option-or-argument state needs
words=( anything '' ) CURRENT=2
Arguably, the -P is covered by the *: action and should be included too.
The relevant code for this is the following two lines in computil.c:
if ((restr = (arg->type == CAA_RARGS)))
restrict_range(ca_laststate.optbeg, ca_laststate.argend);
restrict_range appears to restrict the range based on a start and end
index so is not equipped to remove options interspersed with normal
arguments. So my question for -workers folks is how do we make sense of
struct castate to correct this? I think we need something like
ca_laststate.args along with compwords from ca_laststate.argbeg onwards.
Oliver
Messages sorted by:
Reverse Date,
Date,
Thread,
Author