Completion error message

Completion error message

[Daniel Shahaf]

«rsync -4 -6 --<TAB>» does nothing and prints nothing.

I get why it _does_ nothing — -4 and -6 are mutually exclusive, so the
command line is invalid and it makes no sense to continue — but
shouldn't it print an error message?

Found by Daniel H.

Re: Completion error message

[Oliver Kiddle]

Daniel Shahaf wrote:
> «rsync -4 -6 --<TAB>» does nothing and prints nothing.
>
> I get why it _does_ nothing — -4 and -6 are mutually exclusive, so the
> command line is invalid and it makes no sense to continue — but
> shouldn't it print an error message?

Note that _rsync uses _arguments sets. Without sets, it will complete
further options. With sets, it is aggressive about disabling 
sets such that it can narrow things to the intended set. Unfortunately,
that can easily result in all sets being deactivated.

The inactive option (-6) is seen as an invalid argument when parsing for
each of the two sets. Both sets get disabled and there's no completion.
As I mentioned in 40129, we could do something with marking sets for
fallback and examine them twice.

This also affects things without sets, try this:
  _arguments '(-6)-4' '(-4)-6' -a -b '1:arg1:(1)' '2:arg2:(2)'

The -6 option gets taken as the first positional argument and '2' gets
completed. What do you think it should complete there?
Most commands don't like position arguments to look like options.

I'm not especially keen on producing error messages from completion.

Oliver

Re: Completion error message

[Bart Schaefer]

On Thu, Jan 25, 2018 at 7:50 AM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> «rsync -4 -6 --<TAB>» does nothing and prints nothing.

It beeps, unless of course you have the bell disabled.

> I get why it _does_ nothing — -4 and -6 are mutually exclusive

That may be attributing more understanding to "comparguments -i" than
it actually has.

Re: Completion error message

[Mikael Magnusson]

On Thu, Jan 25, 2018 at 9:24 PM, Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
> Daniel Shahaf wrote:
>> «rsync -4 -6 --<TAB>» does nothing and prints nothing.
>>
>> I get why it _does_ nothing — -4 and -6 are mutually exclusive, so the
>> command line is invalid and it makes no sense to continue — but
>> shouldn't it print an error message?
>
> Note that _rsync uses _arguments sets. Without sets, it will complete
> further options. With sets, it is aggressive about disabling
> sets such that it can narrow things to the intended set. Unfortunately,
> that can easily result in all sets being deactivated.
>
> The inactive option (-6) is seen as an invalid argument when parsing for
> each of the two sets. Both sets get disabled and there's no completion.
> As I mentioned in 40129, we could do something with marking sets for
> fallback and examine them twice.
>
> This also affects things without sets, try this:
>   _arguments '(-6)-4' '(-4)-6' -a -b '1:arg1:(1)' '2:arg2:(2)'
>
> The -6 option gets taken as the first positional argument and '2' gets
> completed. What do you think it should complete there?
> Most commands don't like position arguments to look like options.
>
> I'm not especially keen on producing error messages from completion.

For most other commands you get
% zsh --aoentuh<tab>
---- no match for: `script file', `directory', or `option'

And it's also sort of surprising that _complete_help does nothing at all.

-- 
Mikael Magnusson

Re: Completion error message

[Bart Schaefer]

On Thu, Jan 25, 2018 at 11:21 PM, Mikael Magnusson <mikachu@gmail.com> wrote:
> On Thu, Jan 25, 2018 at 9:24 PM, Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
>> Daniel Shahaf wrote:
>>> «rsync -4 -6 --<TAB>» does nothing and prints nothing.
>>
>> The inactive option (-6) is seen as an invalid argument when parsing for
>> each of the two sets. Both sets get disabled and there's no completion.
>> As I mentioned in 40129, we could do something with marking sets for
>> fallback and examine them twice.
>>
>> I'm not especially keen on producing error messages from completion.
>
> For most other commands you get
> % zsh --aoentuh<tab>
> ---- no match for: `script file', `directory', or `option'
>
> And it's also sort of surprising that _complete_help does nothing at all.

You only get the "no match for: ..." text if you have set the
appropriate zstyle.

However, the lack of both help and description is directly connected
to what Oliver was explaining.  Because all possible sets of
completions are excluded, _arguments never calls _description and
there is nothing for _main_complete to report as the context.

How about this?

BartMAC2014% zstyle ':completion:*:messages' format %S%d%s
BartMAC2014% rsync -4 -6 --
no valid completions

It may have other unintended side-effects, though.

diff --git a/Completion/Base/Utility/_arguments
b/Completion/Base/Utility/_arguments
index 136dd58..7b2bd40 100644
--- a/Completion/Base/Utility/_arguments
+++ b/Completion/Base/Utility/_arguments
@@ -583,5 +583,6 @@ if (( $# )) && comparguments -i "$autod"
"$singopt[@]" "$@"; then

   [[ nm -ne "$compstate[nmatches]" ]]
 else
+  _message "no valid completions"
   return 1
 fi

Re: Completion error message

[Oliver Kiddle]

Bart wrote:
> You only get the "no match for: ..." text if you have set the
> appropriate zstyle.

It also implies that a tag loop was run for particular tags even if
there were no matches.

> How about this?
>
> BartMAC2014% zstyle ':completion:*:messages' format %S%d%s
> BartMAC2014% rsync -4 -6 --
> no valid completions

If this is useful, then it might as well be done at the top-level in
_main_complete, perhaps controlled by a format style. Any function can
produce no matches and not even run through a tag loop–it isn't unique
to _arguments.

There's a variety of different conditions that cause comparguments -i to
return 1 besides all sets being disabled. For a very simple example,
take an arguments spec consisting of just options with no rest arguments,
e.g: _foo() { _arguments -a }, then try completion following a
non-option argument, e.g. foo arg <tab>
If _arguments is used in conjunction with another function (uncommon but
there are uses), the message would be unwanted. Only generating it from
_main_complete allows you to be sure there were no matches at all.

Oliver