return code of _arguments

[Oliver Kiddle <opk@xxxxxxxxxxxxx>]

In a couple of instances, I realised that despite _complete finding
matches, the _approximate completer was also being given a go. For
example, bzip2 --k<tab> was offering loads of other things besides
--keep.

The basic cause of this is that _bzip2 doesn't handle return codes of
300 from _arguments. This is a problem for any completion function
which uses a state machine action for any non-option spec (the *:... or
1:... specs) and is followed by && or || to determine the return code.
There are a good few.

If my understanding is correct the test [[ $? = 300 ]] after _arguments
is going to be equivalent to the test [[ -n $state ]]? The test appears
only twice - in _x_arguments and _xt_arguments so maybe this 300
feature isn't as useful as first anticipated by Sven. I therefore
wonder that the best thing to do here wouldn't be to remove the 300
return-code feature of _arguments and adapt the two functions which
rely on it.

Once we've resolved this, I'll rethink through the return codes for
many of the functions. In cases like _bzip2, the && return 0 is
actually quite handy because you need to use '--' first to compress
files whose names start with a -. If one of the options matched, the
current word must start with a - so we are better not to be completing
files. That said, I'd bet there are a number of functions where return
0 is used but we should be doing ret=0 -- especially any written by me
I fear.

Oliver