Re: [PATCH] Completion batch #5: Simple Darwin and Linux utilities

[dana <dana@xxxxxxx>]

On 5 Jan 2018, at 17:50, Oliver Kiddle <okiddle@xxxxxxxxxxx> wrote:
>That is with the exception of Linux/Command/_ldd – there's already a
>completion for ldd in Unix/Command that also handles Solaris and the
>BSDs.

Oops, i didn't see that. I'd just assumed it was missing because it's actually
broken — at least it is on Ubuntu Xenial. Here is a fix for that:

diff --git a/Completion/Unix/Command/_ldd b/Completion/Unix/Command/_ldd
index 19b8a9105..1de1659a5 100644
--- a/Completion/Unix/Command/_ldd
+++ b/Completion/Unix/Command/_ldd
@@ -1,6 +1,6 @@
 #compdef ldd
 
-if _pick_variant gnu='(GNU|EGLIBC|Gentoo)' unix --version; then
+if _pick_variant gnu='(Free Soft|GNU|EGLIBC|Gentoo)' unix --version; then
   args=(
     '(- *)--version[display version information]'
     '(- *)--help[display help information]'

(Changing 'EGLIBC' to just 'GLIBC' would also do it.)

On 5 Jan 2018, at 17:50, Oliver Kiddle <okiddle@xxxxxxxxxxx> wrote:
>It is also better
>in general to use $words[1] instead of $service in case a command is
>specified by the user with a full path and there's another version of
>the command elsewhere in $PATH.

Ah, that makes sense in hind sight. Would you like a patch to fix the
_call_program and $service stuff you mentioned?

On 5 Jan 2018, at 17:50, Oliver Kiddle <okiddle@xxxxxxxxxxx> wrote:
>The idea is that when looking up styles with zstyle, this should be
>included. Unlike _wanted, _alternative, _tags and others, this can't be
>passed on to _values other than in $curcontext. So in this case, using
>_arguments -C might be better.

Is there any case where -C is actually *undesirable*? I'd asked myself earlier
why it isn't simply the default, and i decided that maybe it was for backwards
compatibility with functions/styles that existed before -C was added...?

On 5 Jan 2018, at 17:50, Oliver Kiddle <okiddle@xxxxxxxxxxx> wrote:
>Can you elaborate on what doesn't work here?

The command doesn't want to take a host name (and so i don't want to complete
one) unless -r has been given. But it's also valid to give it as -rW or -Wr, and
i found that if i tried to give -r its own set the completion system failed to
'detect' that i was in it when i provided the options stacked like that. In
other words, assuming i have a set for -r and friends:

  % scutil -r <tab>  # completes only args from the -r set, as expected
  % scutil -rW <tab> # erroneously completes args from other sets

After some research i found workers/33249, which i assume (?) is related:

http://www.zsh.org/mla/workers/2014/msg01037.html

On 5 Jan 2018, at 17:50, Oliver Kiddle <okiddle@xxxxxxxxxxx> wrote:
>Sets have some oddities and
>are often better avoided.

Yeah, that's the conclusion i came to as well...