zsh-workers
 help / color / mirror / code / Atom feed
* PATCH: minimal dropbox command line completion
@ 2020-08-27 20:15 Peter Stephenson
  2020-08-28  2:22 ` Daniel Shahaf
  0 siblings, 1 reply; 7+ messages in thread
From: Peter Stephenson @ 2020-08-27 20:15 UTC (permalink / raw)
  To: Zsh hackers list

diff --git a/Completion/Unix/Command/_dropbox b/Completion/Unix/Command/_dropbox
new file mode 100644
index 000000000..4dd9c8ad8
--- /dev/null
+++ b/Completion/Unix/Command/_dropbox
@@ -0,0 +1,16 @@
+#compdef dropbox
+
+if [[ CURRENT -eq 2 || $words[2] = help ]]; then
+    local -a line progs
+
+    _call_program commands command dropbox help |
+      while read -A line; do
+	if [[ $line[1] = [a-z]## ]]; then
+	    progs+=("$line[1]:$line[2,-1]")
+	fi
+      done
+
+    _describe -t dropbox-commands 'Dropbox command' progs
+elif [[ $words[2] = (ls|filestatus|sharelink) ]]; then
+ _files
+fi



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: PATCH: minimal dropbox command line completion
  2020-08-27 20:15 PATCH: minimal dropbox command line completion Peter Stephenson
@ 2020-08-28  2:22 ` Daniel Shahaf
  2020-08-28  8:27   ` Peter Stephenson
  0 siblings, 1 reply; 7+ messages in thread
From: Daniel Shahaf @ 2020-08-28  2:22 UTC (permalink / raw)
  To: Peter Stephenson; +Cc: Zsh hackers list

Peter Stephenson wrote on Thu, 27 Aug 2020 21:15 +0100:
> +++ b/Completion/Unix/Command/_dropbox

Relation to [1]?  It uses a different top-of-file directive, but
nevertheless seems to be possibly related.

[1] https://github.com/zpm-zsh/dropbox/blob/master/functions/_dropbox-cli
[2] https://github.com/ivoarch/dropbox-zsh-completion/blob/master/_dropbox

> @@ -0,0 +1,16 @@
> +#compdef dropbox
> +
> +if [[ CURRENT -eq 2 || $words[2] = help ]]; then
> +    local -a line progs
> +
> +    _call_program commands command dropbox help |
> +      while read -A line; do
> +	if [[ $line[1] = [a-z]## ]]; then
> +	    progs+=("$line[1]:$line[2,-1]")

Suggest s/$line[1]/${line[1]}/ for forward compatibility with
a potential future «:$» history modifier.  (And -r to 'read')

> +	fi
> +      done
> +
> +    _describe -t dropbox-commands 'Dropbox command' progs
> +elif [[ $words[2] = (ls|filestatus|sharelink) ]]; then
> + _files

   else
     return 1

> +fi
> 
> 

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.)

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: PATCH: minimal dropbox command line completion
  2020-08-28  2:22 ` Daniel Shahaf
@ 2020-08-28  8:27   ` Peter Stephenson
  2020-08-29  0:38     ` Daniel Shahaf
  0 siblings, 1 reply; 7+ messages in thread
From: Peter Stephenson @ 2020-08-28  8:27 UTC (permalink / raw)
  To: Zsh hackers list


> On 28 August 2020 at 03:22 Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Peter Stephenson wrote on Thu, 27 Aug 2020 21:15 +0100:
> > +++ b/Completion/Unix/Command/_dropbox
> 
> Relation to [1]?  It uses a different top-of-file directive, but
> nevertheless seems to be possibly related.
> 
> [1] https://github.com/zpm-zsh/dropbox/blob/master/functions/_dropbox-cli
> [2] https://github.com/ivoarch/dropbox-zsh-completion/blob/master/_dropbox

I guess they all have the same intention.  The first one complete command
arguments better.

We should probably have something along these lines in the distribution.
I don't really mind which.

pws


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: PATCH: minimal dropbox command line completion
  2020-08-28  8:27   ` Peter Stephenson
@ 2020-08-29  0:38     ` Daniel Shahaf
  2020-08-29 11:45       ` Oliver Kiddle
  0 siblings, 1 reply; 7+ messages in thread
From: Daniel Shahaf @ 2020-08-29  0:38 UTC (permalink / raw)
  To: Peter Stephenson; +Cc: Zsh hackers list

Peter Stephenson wrote on Fri, 28 Aug 2020 09:27 +0100:
> > On 28 August 2020 at 03:22 Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > Peter Stephenson wrote on Thu, 27 Aug 2020 21:15 +0100:  
> > > +++ b/Completion/Unix/Command/_dropbox  
> > 
> > Relation to [1]?  It uses a different top-of-file directive, but
> > nevertheless seems to be possibly related.
> > 
> > [1] https://github.com/zpm-zsh/dropbox/blob/master/functions/_dropbox-cli
> > [2] https://github.com/ivoarch/dropbox-zsh-completion/blob/master/_dropbox  
> 
> I guess they all have the same intention.  The first one complete command
> arguments better.
> 
> We should probably have something along these lines in the distribution.
> I don't really mind which.

I certainly don't have a horse in the race.

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?

If it is, the author's email address is available at
https://github.com/zpm-zsh/dropbox/commit/16f047dae32830e2e1394d8352c241365ebd415a.patch.

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: PATCH: minimal dropbox command line completion
  2020-08-29  0:38     ` Daniel Shahaf
@ 2020-08-29 11:45       ` Oliver Kiddle
  2020-08-29 13:49         ` Peter Stephenson
  2020-08-29 19:58         ` PATCH: minimal dropbox command line completion (and $compstate[nmatches]/$ret) Daniel Shahaf
  0 siblings, 2 replies; 7+ messages in thread
From: Oliver Kiddle @ 2020-08-29 11:45 UTC (permalink / raw)
  To: Zsh hackers list

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: PATCH: minimal dropbox command line completion
  2020-08-29 11:45       ` Oliver Kiddle
@ 2020-08-29 13:49         ` Peter Stephenson
  2020-08-29 19:58         ` PATCH: minimal dropbox command line completion (and $compstate[nmatches]/$ret) Daniel Shahaf
  1 sibling, 0 replies; 7+ messages in thread
From: Peter Stephenson @ 2020-08-29 13:49 UTC (permalink / raw)
  To: zsh-workers

I've written a slightly less minimal completion from scratch.

My eyes may have glazed over on some of the instructions, but I think
I've got most points.

pws


#compdef dropbox

if [[ CURRENT -eq 2 || $words[2] = help ]]; then
  local -a line progs

  _call_program command dropbox help |
    while read -A line; do
	if [[ $line[1] = [a-z]## ]]; then
	  progs+=("${line[1]}:${line[2,-1]}")
	fi
    done

  _describe -t command 'Dropbox command' progs
else
  local -a opts

  case $words[2] in
    (exclude)
    _path_files -g '*(/)'
    ;;

    (filestatus)
    shift words
    (( CURRENT-- ))
    _arguments -s : \
       '(-l --list)'{-l,--list}'[use format like ls]' \
       '(-a --all)'{-a,--all}'[do not ignore entries starting .]' \
       '*:file to list:_files'
    ;;

    (ls|puburl|sharelink)
    _files
    ;;

    (autostart|lansync)
    opts=("y:turn $words[2] on" "n:turn $words[2] off")
    _describe "$words[2] behaviour" opts
    ;;

    (proxy)
    _arguments \
      '2:proxy mode:(none auto manual)' \
      '3:proxy type for manual mode:(http socks4 socks5)' \
      '4:proxy host for manual mode:_hosts' \
      '5:proxy port for manual mode:_ports' \
      '6:proxy user for manual mode:_users' \
      '7:proxy password for manual mode:'
    ;;

    (start)
    shift words
    (( CURRENT -- ))
    _arguments -s : '(-i --install)'{-i,--install}'[auto install dropboxd]'
    ;;

    (throttle)
    _arguments \
      '2:download limit in KB/s:(unlimited)' \
      '3:upload limit in KB/s:(unlimited)'
    ;;

    (*)
    _default
    ;;
  esac
fi



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: PATCH: minimal dropbox command line completion (and $compstate[nmatches]/$ret)
  2020-08-29 11:45       ` Oliver Kiddle
  2020-08-29 13:49         ` Peter Stephenson
@ 2020-08-29 19:58         ` Daniel Shahaf
  1 sibling, 0 replies; 7+ messages in thread
From: Daniel Shahaf @ 2020-08-29 19:58 UTC (permalink / raw)
  To: Oliver Kiddle; +Cc: Zsh hackers list

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-08-29 19:59 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-27 20:15 PATCH: minimal dropbox command line completion 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
2020-08-29 13:49         ` Peter Stephenson
2020-08-29 19:58         ` PATCH: minimal dropbox command line completion (and $compstate[nmatches]/$ret) Daniel Shahaf

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).