Re: PATCH: minimal dropbox command line completion

[Oliver Kiddle <opk@xxxxxxx>]

Daniel Shahaf wrote:
> I guess merging [1] and extending it would be the best option
> technically.  However, that file appears to be under the GPLv3 (per the
> LICENSE file in its repository).  Is that a problem?

I think we should avoid doing that if at all possible. Where we've had
functions under different licences it can create more work for people
packaging zsh than it would be to just rewrite the function. Different
distributions and operating systems have different rules, some remove
them, some add complicated merged licence files and many ignore it.
I should probably revisit that idea of having a separate Contrib
directory for some functions. It was partly stalled on the naming.

To me it would seem bad form to simply take something found elsewhere
without successfully contacting the author. If you get an answer,
chances are they'll be more than happy to contribute it under the zsh
licence.

Otherwise, the best approach would be to simply commit Peter's function
and the name clash with the others may encourage people to contribute
improvements.

> > +    _call_program commands command dropbox help |

The tag passed to _call_program should match the tag passed to _describe
when resultant matches are added.

In general I think it is preferable to generate matches from help output
like this rather than hardcode lists as done in the functions Daniel linked
to.

> > +elif [[ $words[2] = (ls|filestatus|sharelink) ]]; then
> > + _files

When handling subcommands, it is always a good idea to fallback on
calling _default wherever you have a subcommand for which there is no
special treatment. Don't break file completion probably the most
important rule of writing custom completions.

> Aside: I wonder why we don't use a «_call_completion_function()
> { readonly -i n=$compstate[nmatches]; "$@" && (( $compstate[nmatches] > $n)) }»
> wrapper around calls to $_comps[foo]: that'd save every single
> completion function having to manage $ret explicitly.)

The original concept was that there would be cases where you explicitly
want to allow completion to continue despite having added matches.
In practice this is very rare but does occur. Also, we rely on the
return status in many more places than just the calls of $_comps[foo] in
_dispatch. Getting it wrong tends to be most apparent from _approximate
acting when it shouldn't but it can break other things such as tag
loops.

It could be possible to redesign this if we allow breaking changes
sometime. Perhaps with keys in $compstate to indicate continuation.

Oliver