zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <opk@zsh.org>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: PATCH: minimal dropbox command line completion
Date: Sat, 29 Aug 2020 13:45:45 +0200	[thread overview]
Message-ID: <61559-1598701545.540695@NVxH.JTOI.LNn_> (raw)
In-Reply-To: <20200829003857.0a14a362@tarpaulin.shahaf.local2>

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


  reply	other threads:[~2020-08-29 11:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-27 20:15 Peter Stephenson
2020-08-28  2:22 ` Daniel Shahaf
2020-08-28  8:27   ` Peter Stephenson
2020-08-29  0:38     ` Daniel Shahaf
2020-08-29 11:45       ` Oliver Kiddle [this message]
2020-08-29 13:49         ` Peter Stephenson
2020-08-29 19:58         ` PATCH: minimal dropbox command line completion (and $compstate[nmatches]/$ret) Daniel Shahaf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=61559-1598701545.540695@NVxH.JTOI.LNn_ \
    --to=opk@zsh.org \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).