From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5855 invoked from network); 29 Aug 2020 11:46:13 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 29 Aug 2020 11:46:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20200801; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Message-ID:Date: Content-Transfer-Encoding:Content-ID:Content-Type:MIME-Version:Subject:To: References:From:In-reply-to:Reply-To:Cc:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=UF6XxzEYC8VNh/x8/TPqJHlzV+qBVUuMTu29dVxj1A0=; b=Cm7qy3nnrs8lBhkVDH15RJFAly mk7GkplHvSrdKrURDkCvdZFmVZL/antAuL0H5NQEQKvXdBVYZqg+tKFOU0Y+muXxyrmQBgYmVcLEB 6F70fhDmnwARK+pnYvIULCWR0w/jSCwLrRayMWa01RTBKKvIyEULKvp6AavWR11KznNuZJVGw+5zv GN0Mvwh3engXTX58EwmL9iO/nWbQtfvBEzZJq28ZhxnPHwRjswbCxHOZzY0w1LwdgJULulZl+8GMV 5T+7K277NrQd4RpWglGMxP+jhq7Tp448UzvLdAEL5BHcrj4GH75qtzITAK406oPwRPnidJ/BTEgZQ XGAAt7TA==; Received: from authenticated user by zero.zsh.org with local id 1kBzJ6-0002lx-JI; Sat, 29 Aug 2020 11:46:04 +0000 Received: from authenticated user by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1kBzIp-0002d7-4u; Sat, 29 Aug 2020 11:45:47 +0000 Received: from [192.168.178.21] (helo=hydra) by mail.kiddle.eu with esmtp(Exim 4.93.0.4) (envelope-from ) id 1kBzIn-000G0u-HX for zsh-workers@zsh.org; Sat, 29 Aug 2020 13:45:45 +0200 In-reply-to: <20200829003857.0a14a362@tarpaulin.shahaf.local2> From: Oliver Kiddle References: <20200828022232.0914170c@tarpaulin.shahaf.local2> <842686448.1489803.1598603222115@mail2.virginmedia.com> <20200829003857.0a14a362@tarpaulin.shahaf.local2> To: Zsh hackers list Subject: Re: PATCH: minimal dropbox command line completion MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <61558.1598701545.1@hydra> Content-Transfer-Encoding: 8bit Date: Sat, 29 Aug 2020 13:45:45 +0200 Message-ID: <61559-1598701545.540695@NVxH.JTOI.LNn_> X-Seq: 47349 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Archived-At: 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