If I type % git switch -c^D then completion shows only -c Instead, I would like it to show all matching completions with descriptions: --conflict change how conflicting hunks are presented --create -c create and switch to a new branch I want this even when there is only one matching option. How do I configure this?
On Tue, Aug 31, 2021 at 1:05 PM Marlon Richert <marlon.richert@gmail.com> wrote:
>
> If I type
>
> % git switch -c^D
>
> then completion shows only
>
> -c
>
> Instead, I would like it to show all matching completions with descriptions:
>
> --conflict change how conflicting hunks
> are presented
> --create -c create and switch to a new
> branch
>
> I want this even when there is only one matching option.
>
> How do I configure this?
There is accept-exact style. You'll also need to arrange for
--conflict to match against -c (this isn't true by default).
Roman.
On Tue, Aug 31, 2021 at 4:11 AM Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote: > > On Tue, Aug 31, 2021 at 1:05 PM Marlon Richert <marlon.richert@gmail.com> wrote: > > > > If I type > > > > % git switch -c^D > > > > [...] I would like it to show all matching completions with descriptions: > > There is accept-exact style. I don't think that applies here. Even if it did, wouldn't it have the opposite effect of what he wants? > You'll also need to arrange for > --conflict to match against -c (this isn't true by default). That might be all that's needed; a matcher-list entry that allows '-' to become '--'. But I suspect there's something deeper going on in the _git suite.
On Tue, Aug 31, 2021 at 7:22 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Tue, Aug 31, 2021 at 4:11 AM Roman Perepelitsa
> <roman.perepelitsa@gmail.com> wrote:
> >
> > There is accept-exact style.
>
> I don't think that applies here. Even if it did, wouldn't it have the
> opposite effect of what he wants?
I meant that accept-exact needs to be off. Marlon didn't specify what
config he's using, so I mentioned everything I thought of that could
prevent ambiguous matches from being displayed.
Roman.
On Tue, Aug 31, 2021 at 10:22 AM Bart Schaefer
<schaefer@brasslantern.com> wrote:
>
> That might be all that's needed; a matcher-list entry that allows '-'
> to become '--'. But I suspect there's something deeper going on in
> the _git suite.
Indeed, the _git suite of functions almost always use _alternative,
which calls _describe with a hardcoded matcher which is prefixed to
whatever appears in the matcher_list style. On line 41 of
_alternative:
_describe -t "${def%%:*}" "$descr" ws -M 'r:|[_-]=* r:|=*' "$subopts[@]"
I believe that makes it impossible to write a matcher-list zstyle that
will swap out "-" with "--" in the context where Marlon wants it. Can
someone demonstrate a workaround?
On Wed, Sep 1, 2021 at 3:23 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Tue, Aug 31, 2021 at 10:22 AM Bart Schaefer
> <schaefer@brasslantern.com> wrote:
> >
> > That might be all that's needed; a matcher-list entry that allows '-'
> > to become '--'. But I suspect there's something deeper going on in
> > the _git suite.
>
> Indeed, the _git suite of functions almost always use _alternative,
> which calls _describe with a hardcoded matcher which is prefixed to
> whatever appears in the matcher_list style. On line 41 of
> _alternative:
>
> _describe -t "${def%%:*}" "$descr" ws -M 'r:|[_-]=* r:|=*' "$subopts[@]"
>
> I believe that makes it impossible to write a matcher-list zstyle that
> will swap out "-" with "--" in the context where Marlon wants it. Can
> someone demonstrate a workaround?
Thank you all, but unfortunately, none of this is addressing the
actual problems I'm trying to solve. Let me try to rephrase:
# Problem number 1
When I type, for example,
git switch -c^D
then completion shows me only
-c
instead of
-c create and switch to a new
I would like to be able to see the description to check if I'm
actually using the right option.
# Problem number 2
When I type, for example,
git switch -c^D
then completion shows me only
-c
_even if_ I have a matcher (of which the details are not important for
this question) that would actually also match --conflict and --create.
The problem is not in the _git completer (I'm just using `git switch
-c` as an example here) nor in my matchers; the problem is in
_arguments. For whatever reason, if there is a single option that
matches exactly, _arguments decides not to print any description for
it _and_ also refuses to complete any other matching options at that
point.
Is there a way around this? Or have I run into an _arguments bug? The
relevant code can be found on lines 489 - 525:
if [[ -z "$alwopt" || -z "$tried" || "$alwopt" = arg ]] &&
comparguments -s single; then
if [[ "$single" = direct ]]; then
_all_labels options expl option \
compadd -QS '' - "${PREFIX}${SUFFIX}"
elif [[ -z "$optarg" && "$single" = next ]]; then
_all_labels options expl option \
compadd -Q - "${PREFIX}${SUFFIX}"
elif [[ "$single" = equal ]]; then
_all_labels options expl option \
compadd -QqS= - "${PREFIX}${SUFFIX}"
else
tmp1=( "$next[@]" "$direct[@]" "$odirect[@]" "$equal[@]" )
[[ "$PREFIX" = [-+]* ]] && tmp1=( "${(@M)tmp1:#${PREFIX[1]}*}" )
[[ "$single" = next ]] &&
tmp1=( "${(@)tmp1:#[-+]${PREFIX[-1]}((#e)|:*)}" )
[[ "$PREFIX" != --* ]] && tmp1=( "${(@)tmp1:#--*}" )
tmp3=( "${(M@)tmp1:#[-+]?[^:]*}" )
tmp1=( "${(M@)tmp1:#[-+]?(|:*)}" )
tmp2=( "${PREFIX}${(@M)^${(@)${(@)tmp1%%:*}#[-+]}:#?}" )
_describe -O option \
tmp1 tmp2 -Q -S '' -- \
tmp3 -Q
[[ -n "$optarg" && "$single" = next && nm -eq
$compstate[nmatches] ]] &&
_all_labels options expl option \
compadd -Q - "${PREFIX}${SUFFIX}"
fi
single=yes
On 31 Aug, Marlon Richert wrote:
> If I type
>
> % git switch -c^D
>
> then completion shows only
> -c
This can be reproduced with just _arguments -s '-c[desc]'
The code relevant to this is this part of _arguments:
346 if comparguments -O next direct odirect equal; then
347 opts=yes
348 _tags options
349 elif [[ $? -eq 2 ]]; then
350 compadd -Q - "${PREFIX}${SUFFIX}"
351 return 0
The comparguments -O has decided that there are no possible completion
matches which is arguably true because -c is already there and, because
we passed -s to _arguments, it is now trying to complete further options
after -c. It looks like there is special handling for this case that has
only considered actual completion because it is doing a plain compadd
without descriptions.
A similar case would be _arguments -s '-c[desc]' -d
and -dc^D
That prints 'no arguments'
A fix would need to be done within the C code for comparguments -O and
it'd probably be hard to do without breaking it more than fixing it.
Oliver
On Thu, Sep 2, 2021 at 1:27 PM Oliver Kiddle <opk@zsh.org> wrote:
>
> The comparguments -O has decided that there are no possible completion
> matches which is arguably true because -c is already there and, because
> we passed -s to _arguments, it is now trying to complete further options
To rephrase this in English, one step up the chain, the difficulty is
that we've told _arguments that short options can be stacked, so -c
could just be the first in a string of single letter options all in
the same shell word.