Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: minimal dropbox command line completion (and $compstate[nmatches]/$ret)
- X-seq: zsh-workers 47351
- From: Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>
- To: Oliver Kiddle <opk@xxxxxxx>
- Subject: Re: PATCH: minimal dropbox command line completion (and $compstate[nmatches]/$ret)
- Date: Sat, 29 Aug 2020 19:58:35 +0000
- Archived-at: <https://zsh.org/workers/47351>
- Archived-at: <http://www.zsh.org/sympa/arcsearch_id/zsh-workers/2020-08/20200829195835.3f1b224b%40tarpaulin.shahaf.local2>
- Authentication-results: zsh.org; iprev=pass (out5-smtp.messagingengine.com) smtp.remote-ip=66.111.4.29; dkim=pass header.d=daniel.shahaf.name header.s=fm1 header.a=rsa-sha256; dkim=pass header.d=messagingengine.com header.s=fm3 header.a=rsa-sha256; dmarc=skipped; arc=none
- Cc: Zsh hackers list <zsh-workers@xxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=date:from:to:cc:subject:message-id :in-reply-to:references:mime-version:content-type :content-transfer-encoding; s=fm1; bh=/Fkaj8ZLc2eeMcYg1owMVbAxP4 e7SXqyM3Fqs8wqlzo=; b=AhlDPT2nbI56CRBI+E79mxtFgqfzX8KSI6iNYjFHCM v/rIw8QyE5sOQ3VxPVdbMbwGIeukujitalC9iNsGcVrHngnO8Cyi7EERdfa3YSLh 8bo3763K1FakouzkIXn0cfvE0ZIGYr9xAWZuzvBGbk4zTd50Vl1D89QVe1VvmtNA WrFkRu/TueHnTVeQgttizrHaD3+XItfPEyuEkORg2JBGLDqTMy/CQ/d/cEgM+P27 2Pg2IPXAOVoSG4ZkEVjoada3DBvNH4mOevaKNmKFWjwstb7Uk3m2efBlUl3aagL0 UXAOg9Xw/kK/yMME7zJXa9bKa+nfRTZz3amxlwlV+uLg==
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=/Fkaj8ZLc2eeMcYg1owMVbAxP4e7SXqyM3Fqs8wql zo=; b=mkjxcIbXXU+wlVzG/2CGcPWTcKRbu8Jb1oQNl4TPxBs9gxcZyv7Ow4S+N pZXZHGVWhSdEwUPy/RTckOyq1xuzOxXCvUErqhDP0VZUJayIJGnbWcdF4SogLAyU 8MtNjqZ/fScGaGHnmA+YyVXOd0IeUjRFDojSH3k9SzPS97ib5eGxQm7StXFuA/0k 7Of79FKAZ61vn7c4QE3pg1gzIgIMjAKAvXOBaJ1ckBjtskHwYwarz9Hp631cR7v0 LVrXCN7iLYUzFb8Nvw0KvEwQyY0VKqVNxZA0eD10Zc7nrZ4YZ8cNJNZFI6H/I1ad C/qKN8l021agGfuDFTpMwouJdVd+w==
- In-reply-to: <61559-1598701545.540695@NVxH.JTOI.LNn_>
- List-archive: <http://www.zsh.org/sympa/arc/zsh-workers>
- List-help: <mailto:sympa@zsh.org?subject=help>
- List-id: <zsh-workers.zsh.org>
- List-owner: <mailto:zsh-workers-request@zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- List-subscribe: <mailto:sympa@zsh.org?subject=subscribe%20zsh-workers>
- List-unsubscribe: <mailto:sympa@zsh.org?subject=unsubscribe%20zsh-workers>
- References: <ee24c5f032cd407c4677b670fc297f7152868ed8.camel@ntlworld.com> <20200828022232.0914170c@tarpaulin.shahaf.local2> <842686448.1489803.1598603222115@mail2.virginmedia.com> <20200829003857.0a14a362@tarpaulin.shahaf.local2> <61559-1598701545.540695@NVxH.JTOI.LNn_>
- Sender: zsh-workers-request@xxxxxxx
Oliver Kiddle wrote on Sat, 29 Aug 2020 13:45 +0200:
> 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.
To be clear, I wasn't proposing we just copy code from github to
zsh.git without contacting authors. I was analyzing the problem from
different angles (technical, legal, social), each one separately, and
then combined the answers.
> 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.
Add this to the documentation somewhere?
> > 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.
Thanks for the explanation!
Cheers,
Daniel
Messages sorted by:
Reverse Date,
Date,
Thread,
Author