PATCH: Fall back to file completion if nothing else works

PATCH: Fall back to file completion if nothing else works

[Frank Terbeck]

Some people have for third party add-ons to git. `annex' is one such
add-on. Currently "git annex add <tab>" does nothing, because there is
no special subcommand handling function.

_git should really fallback to file name completion in such cases. This
patch does exactly that.

I'm wondering how we should handle third party add ons to commands. _git
used provide the `user-commands' style to do stuff like this:

    % zstyle ':completion:*:*:git:*' user-commands foo:'description for foo'

You could even define `_git-foo()' to have special handling.

In fact, the current _git still mentions that in the `user-commands'
style. But the actual code is gone since the major update. I think it
should be re-added for backward compatibility.

`user-commands' is really only useful for user-specific add-ons. We
might also want to invent something so third party add-ons (which might
be distributed separately from git) could drop a _git-foo file into
$fpath to get special completion for "git fo<tab>" and "git foo <tab>".

Thoughts?
---
 Completion/Unix/Command/_git |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index e062705..2b8b8d6 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -6024,6 +6024,10 @@ _git() {
         curcontext=${curcontext%:*:*}:git-$words[1]:
 
         _call_function ret _git-$words[1]
+        if (( ? != 0 )); then
+            _path_files
+            ret=$?
+        fi
         ;;
     esac
   else
-- 
1.7.5

Re: PATCH: Fall back to file completion if nothing else works

[Johan Sundström]

[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]

On Mon, Jun 27, 2011 at 14:55, Frank Terbeck <ft@bewatermyfriend.org> wrote:

> Some people have for third party add-ons to git. `annex' is one such
> add-on. Currently "git annex add <tab>" does nothing, because there is
> no special subcommand handling function.
>
> _git should really fallback to file name completion in such cases. This
> patch does exactly that.
>

-0. As I read this, you're proposing going from 0 (or close to it?) to an
unbounded number of completion false positives.

Before such a patch, you can be sure that git <anything> <tab> will complete
something that is legal in this spot: a tag or branch name, for instance, a
file which has not yet been added to the index, a flag for this command, et
cetera.

After it, one can never know whether zsh completed a filename because that
particular filename was legal in this context, or just because it didn't
know how to complete something in the given context – the completion could
be super smart, but it wouldn't be possible to tell, since you can't know if
a completion was legal without knowing git inside and out, or from running
the command line.

I'm wondering how we should handle third party add ons to commands. _git
> used provide the `user-commands' style to do stuff like this:
>
>    % zstyle ':completion:*:*:git:*' user-commands foo:'description for foo'
>
> You could even define `_git-foo()' to have special handling.
>

I think that sounds like a better way to enable the behaviour you seek, for
people that specifically want it.

-- 
 / Johan Sundström, http://ecmanaut.blogspot.com/

Re: PATCH: Fall back to file completion if nothing else works

[Frank Terbeck]

Johan Sundström wrote:
> On Mon, Jun 27, 2011 at 14:55, Frank Terbeck <ft@bewatermyfriend.org> wrote:
>
>> Some people have for third party add-ons to git. `annex' is one such
>> add-on. Currently "git annex add <tab>" does nothing, because there is
>> no special subcommand handling function.
>>
>> _git should really fallback to file name completion in such cases. This
>> patch does exactly that.
>>
>
> -0. As I read this, you're proposing going from 0 (or close to it?) to an
> unbounded number of completion false positives.
>
> Before such a patch, you can be sure that git <anything> <tab> will complete
> something that is legal in this spot: a tag or branch name, for instance, a
> file which has not yet been added to the index, a flag for this command, et
> cetera.
>
> After it, one can never know whether zsh completed a filename because that
> particular filename was legal in this context, or just because it didn't
> know how to complete something in the given context – the completion could
> be super smart, but it wouldn't be possible to tell, since you can't know if
> a completion was legal without knowing git inside and out, or from running
> the command line.

What? Non sense.

I don't know how you understood the code, but

  zsh% git an-existing-known-subcommand <tab>

will *never* run into this fall back and complete file names, because
the subcommand completion function for `an-existing-known-subcommand'
will know what to do. The *only* thing this does is to fall back to file
name completion when _git doesn't know the subcommand in question.

Doing noting in that spot is entirely useless. And that's what's
happening with the current code.

Also, the old _git did fall back to file completion, too, after
zsh-workers-28411 <http://www.zsh.org/mla/workers/2010/msg00855.html>,
because offering file names when you don't know any better is vastly
more useful than just sitting on your hands doing nothing.

I'm pretty sure changing this behaviour was an unintended oversight when
Nikolai rewrote `_git'.


>> I'm wondering how we should handle third party add ons to commands. _git
>> used provide the `user-commands' style to do stuff like this:
>>
>>    % zstyle ':completion:*:*:git:*' user-commands foo:'description for foo'
>>
>> You could even define `_git-foo()' to have special handling.
>>
>
> I think that sounds like a better way to enable the behaviour you seek, for
> people that specifically want it.

No, it's not.  The behaviour I really want is for _git to accept real
completion add ons. The problem with the `user-commands' commands style
is, that add-ons can't really use it because they will never know which
style to add their description to.

You can already defined `_git-foo()' and it'll be picked up as a
sub-command completion. So the "git foo <tab>" situation would be
solvable. You'd have to manually load the _git-foo completion file
currently or put #autoload into it. I think _git should handle loading
of _git-* files itself so add-ons just had to drop their completion
somewhere into $fpath.

Then _git could register the command name, too and "git fo<tab>" would
suggest `foo' as well. That way we could also drop my "use `foo' from
git-foo binaries from $path" path.


As for `user-commands': It *was* in the old _git. And I know people who
use it. Throwing away existing functionality without good reason or
telling anybody is just bad behaviour.

Though, I am pretty sure this - again - was just an oversight when
Nikolai rewrote `_git', which was a quite the task on to pull off on his
own. Otherwise he would have removed the comment on top of _git, too.

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

Re: PATCH: Fall back to file completion if nothing else works

[Johan Sundström]

[-- Attachment #1: Type: text/plain, Size: 3904 bytes --]

On Mon, Jun 27, 2011 at 22:17, Frank Terbeck <ft@bewatermyfriend.org> wrote:

> > -0. As I read this, you're proposing going from 0 (or close to it?) to an
> > unbounded number of completion false positives.
> >
> > Before such a patch, you can be sure that git <anything> <tab> will
> complete
> > something that is legal in this spot: a tag or branch name, for instance,
> a
> > file which has not yet been added to the index, a flag for this command,
> et
> > cetera.
> >
> > After it, one can never know whether zsh completed a filename because
> that
> > particular filename was legal in this context, or just because it didn't
> > know how to complete something in the given context – the completion
> could
> > be super smart, but it wouldn't be possible to tell, since you can't know
> if
> > a completion was legal without knowing git inside and out, or from
> running
> > the command line.
>
> What? Non sense.
>
> I don't know how you understood the code, but
>
>  zsh% git an-existing-known-subcommand <tab>
>
> will *never* run into this fall back and complete file names, because
> the subcommand completion function for `an-existing-known-subcommand'
> will know what to do. The *only* thing this does is to fall back to file
> name completion when _git doesn't know the subcommand in question.
>

I didn't, and that is a bit less damaging than what I understood it for.

Anyway, my -0 doesn't carry much weight here; it is just opinion and my
reasoning behind it. I personally prefer that in cases zsh completion
doesn't know what to complete, it won't try something that might, or might
not, be semantically valid for the command line.

Doing noting in that spot is entirely useless. And that's what's
> happening with the current code.
>

I disagree. It tells me "when _git doesn't know the subcommand in question"
(so I could fix it to do the right thing, should I care to), and it would
never fill in something which might be wrong there instead of engaging a
blind, "best-effort" auto pilot.

This is one of those preference things where a behaviour somebody (your or
me) prefers isn't right or wrong, but where taste just differs among people.

In the unlikely event this was a heated topic among the majority of list
lurkers, and we saw a storm -1 chime-ins and another smaller trickle or
larger still mass of +1:s, the majority vote might not be a good thing to
implement. I think that's what zsh's whole configurable completion system is
all about, at heart; not implementing one size fits all wholesale behaviour.

>> You could even define `_git-foo()' to have special handling.
> >
> > I think that sounds like a better way to enable the behaviour you seek,
> for
> > people that specifically want it.
>
> No, it's not.  The behaviour I really want is for _git to accept real
> completion add ons.


Ah, I thought that was where you were going. This sounds useful to me, too.

You can already defined `_git-foo()' and it'll be picked up as a
> sub-command completion. So the "git foo <tab>" situation would be
> solvable. You'd have to manually load the _git-foo completion file
> currently or put #autoload into it. I think _git should handle loading
> of _git-* files itself so add-ons just had to drop their completion
> somewhere into $fpath.
>
> Then _git could register the command name, too and "git fo<tab>" would
> suggest `foo' as well. That way we could also drop my "use `foo' from
> git-foo binaries from $path" path.
>

I think this kind of completion plugin plugins can benefit more than git, as
other commands (like npm and [home]brew) are using command line
styles similar to git's (rpm, dpkg, and probably other package managers do,
too, even though I guess most don't have as much user extensibility).

Best,

-- 
 / Johan Sundström, http://ecmanaut.blogspot.com/

Re: PATCH: Fall back to file completion if nothing else works

[Frank Terbeck]

Johan Sundström wrote:
> Anyway, my -0 doesn't carry much weight here; it is just opinion and my
> reasoning behind it. I personally prefer that in cases zsh completion
> doesn't know what to complete, it won't try something that might, or might
> not, be semantically valid for the command line.
[...]
> This is one of those preference things where a behaviour somebody (your or
> me) prefers isn't right or wrong, but where taste just differs among people.

Fair enough.  Still, I think it would be pretty much in line with how
the rest of compsys works. Say there's a program for which there is no
special completion, then compsys falls back to completing
files. Actually, the command doesn't even have to be a valid
command. Compsys will still fall back to completing files:

  zsh% doesntexist <tab>

...will complete files.

And since the old `_git' behaved like that, too. I think it's the right
thing to do[tm], per default.

If it's really really annoying enough for you and others we could always
put in a boolean style and make that behaviour configurable via
`zstyle'. We could make zsh say "Unknown sub-command" in that case to,
if the fall-back was disabled by the user...

[...]
>> No, it's not.  The behaviour I really want is for _git to accept real
>> completion add ons.
>
> Ah, I thought that was where you were going. This sounds useful to me, too.

Yeah, just send a patch that implements something like that.

Regards, Frank

PATCH: (0/3) _git fixes and enhancements

[Frank Terbeck]

Hey list!

This is a small series that (hopefully) improves _git a little.


_git: Fall back to file completion if nothing else works

    The first patch does basically the same as the one from
    workers-29512 did. But on IRC Mikael reminded me of workers-29453,
    which basically makes the point that most sub-command completions
    are not suited to be used with `_call_function', since they set
    `ret' themselves.

    Therefore, the second patch removes the use of `_call_function' and
    just calls the sub-command completion directly (just like Mikael did
    in `workers-29453').

    The file-completion fallback is only used if `_git-foo()' is not
    defined. So, the completion behaviour of know sub-commands does
    *not* change at all.

    workers-29512: <http://www.zsh.org/mla/workers/2011/msg00946.html>
    workers-29453: <http://www.zsh.org/mla/workers/2011/msg00887.html>


_git: Pick up addon completions from $fpath

    The second patch goes ahead and collects all `_git-*' completion
    files from `$fpath' and makes them available for:

    % git <tab>

    There is optional support for specifying a description for the addon
    command in the second line of the function if file, if that second
    line matches "#desc:*". Such a completion may look like this (say,
    this is a file called `_git-foo'):

    [snip]
    #compdef git-foo
    #desc:checks git's foobar value
    [...]
    [snap]

    With this, the patch from workers-29514 isn't needed anymore. I'll
    drop it therefore.


_git: re-add `user-commands' support again

    The third patch just re-adds the use of the `user-commands' style
    like it's documented on top of `_git'. This (probably) got
    accidentally dropped when Nikolai did the major `_git'-update.


 Completion/Unix/Command/_git |   50 +++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 49 insertions(+), 1 deletions(-)

PATCH: (1/3) _git: Fall back to file completion if nothing else works

[Frank Terbeck]

---
 Completion/Unix/Command/_git |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index e062705..362ec78 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -6023,7 +6023,12 @@ _git() {
       (option-or-argument)
         curcontext=${curcontext%:*:*}:git-$words[1]:
 
-        _call_function ret _git-$words[1]
+        if (( ${+functions[_git-$words[1]]} )); then
+            _git-$words[1]
+        else
+            _path_files
+            ret=$?
+        fi
         ;;
     esac
   else
-- 
1.7.6

PATCH: (2/3) _git: Pick up addon completions from $fpath

[Frank Terbeck]

---
 Completion/Unix/Command/_git |   39 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index 362ec78..ef97499 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -4603,6 +4603,7 @@ _git_commands () {
   _describe -t plumbing-sync-commands 'plumbing sync command' plumbing_sync_commands && ret=0
   _describe -t plumbing-sync-helper-commands 'plumbing sync helper command' plumbing_sync_helper_commands && ret=0
   _describe -t plumbing-internal-helper-commands 'plumbing internal helper command' plumbing_internal_helper_commands && ret=0
+  _describe -t third-party-addons 'third party addon' _git_third_party && ret=0
   return ret
 }
 
@@ -6037,4 +6038,42 @@ _git() {
   return ret
 }
 
+# Handle add-on completions. Say you got a third party add-on `foo'. What you
+# want to do is write your completion as `_git-foo' and this code will pick it
+# up. That should be a regular compsys function, which starts like this:
+#
+#  #compdef git-foo
+#
+# In addition to what compinit does, this also reads the second line of the
+# completion. If that matches "#desc:*" the part behind "#desc:" will be used
+# as the addon's description. Like this:
+#
+#  #desc:checks git's foobar value
+local addon input i desc
+typeset -gUa _git_third_party
+for addon in ${^fpath}/_git-*~*~(.N); do
+    if [[ -n ${(M)_git_third_party:#${${addon:t}#_git-}*} ]]; then
+        # This makes sure only the first _git-foo in $fpath gets read.
+        continue
+    fi
+    # Read the second line of the file.
+    i=1
+    desc=
+    while read input; do
+        if (( i == 2 )); then
+            desc=$input
+            break
+        fi
+        (( i++ ))
+    done < $addon
+    # Setup `$desc' appropriately.
+    if [[ $desc != '#desc:'* ]]; then
+        desc=
+    else
+        desc=${desc#\#desc}
+    fi
+    # Add the addon's completion.
+    _git_third_party+=( ${${addon:t}#_git-}$desc )
+done
+
 _git
-- 
1.7.6

Re: PATCH: (2/3) _git: Pick up addon completions from $fpath

[Frank Terbeck]

Frank Terbeck wrote:
> +  _describe -t third-party-addons 'third party addon' _git_third_party && ret=0

Actually, just because the completion is there doesn't mean that
completing the thing at "git <tab>" makes sense, because the addon
program may not even be installed on the system in question.

For example, we're already shipping `_git-buildpackage'. But on a system
where `git-buildpackage' is not installed, I wouldn't want it to appear
in suggestions for "git b<tab>".

Here's something on top of the previous patch to take such situations
into account. I'd squash these two, before committing to CVS.

Regards, Frank


diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index 4567460..a1856df 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -4606,7 +4606,12 @@ _git_commands () {
   _describe -t plumbing-sync-commands 'plumbing sync command' plumbing_sync_commands && ret=0
   _describe -t plumbing-sync-helper-commands 'plumbing sync helper command' plumbing_sync_helper_commands && ret=0
   _describe -t plumbing-internal-helper-commands 'plumbing internal helper command' plumbing_internal_helper_commands && ret=0
-  _describe -t third-party-addons 'third party addon' _git_third_party && ret=0
+  local -a addons
+  local a
+  for a in $_git_third_party; do
+      (( ${+commands[git-${a%%:*}]} )) && addons+=( $a )
+  done
+  _describe -t third-party-addons 'third party addon' addons && ret=0
   _describe -t user-specific-commands 'user specific command' user_commands && ret=0
   return ret
 }

PATCH: (3/3) _git: re-add `user-commands' support again

[Frank Terbeck]

---
 Completion/Unix/Command/_git |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index ef97499..4567460 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -4439,6 +4439,9 @@ __git_ignore_line_inside_arguments () {
 
 (( $+functions[_git_commands] )) ||
 _git_commands () {
+  local -a user_commands
+  zstyle -a ":completion:${curcontext}:" user-commands user_commands || user_commands=()
+
   local -a main_porcelain_commands
   main_porcelain_commands=(
     add:'add file contents to index'
@@ -4604,6 +4607,7 @@ _git_commands () {
   _describe -t plumbing-sync-helper-commands 'plumbing sync helper command' plumbing_sync_helper_commands && ret=0
   _describe -t plumbing-internal-helper-commands 'plumbing internal helper command' plumbing_internal_helper_commands && ret=0
   _describe -t third-party-addons 'third party addon' _git_third_party && ret=0
+  _describe -t user-specific-commands 'user specific command' user_commands && ret=0
   return ret
 }
 
-- 
1.7.6

Re: PATCH: (3/3) _git: re-add `user-commands' support again

[Nikolai Weibull]

I’m going to change the order of the tags to be

main-porcelain-commands
user-commands
third-party-commands
…

I prefer “user-commands” as a tag name over “user-specific-commands”
as it matches the style name.

My reasoning for this order is that you always want the main porcelain
commands listed first. Then, any commands defined through the zstyle
will most likely be of most interest to the user.  Third-party
commands are tricky, however, as their relevance to the user may or
may not be high.  I think having them before
ancillary-manipulator-commands makes sense, but perhaps someone
disagrees?

On Wed, Jun 29, 2011 at 22:37, Frank Terbeck <ft@bewatermyfriend.org> wrote:
> ---
>  Completion/Unix/Command/_git |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
> index ef97499..4567460 100644
> --- a/Completion/Unix/Command/_git
> +++ b/Completion/Unix/Command/_git
> @@ -4439,6 +4439,9 @@ __git_ignore_line_inside_arguments () {
>
>  (( $+functions[_git_commands] )) ||
>  _git_commands () {
> +  local -a user_commands
> +  zstyle -a ":completion:${curcontext}:" user-commands user_commands || user_commands=()
> +
>   local -a main_porcelain_commands
>   main_porcelain_commands=(
>     add:'add file contents to index'
> @@ -4604,6 +4607,7 @@ _git_commands () {
>   _describe -t plumbing-sync-helper-commands 'plumbing sync helper command' plumbing_sync_helper_commands && ret=0
>   _describe -t plumbing-internal-helper-commands 'plumbing internal helper command' plumbing_internal_helper_commands && ret=0
>   _describe -t third-party-addons 'third party addon' _git_third_party && ret=0
> +  _describe -t user-specific-commands 'user specific command' user_commands && ret=0
>   return ret
>  }

Re: PATCH: (3/3) _git: re-add `user-commands' support again

[Nikolai Weibull]

Do we really need this style?  I don’t like it at all.  If the user
wants to add completion for a sub-command they should really go the
extra distance and add a proper completion definition for the whole
sub-command.  It’s not hard to add a _git-subcommand file under
~/.zsh/functions (or similar) with a proper description and all.

If you don’t disagree I’m going to remove it.

On Wed, Jun 29, 2011 at 22:37, Frank Terbeck <ft@bewatermyfriend.org> wrote:
> ---
>  Completion/Unix/Command/_git |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
> index ef97499..4567460 100644
> --- a/Completion/Unix/Command/_git
> +++ b/Completion/Unix/Command/_git
> @@ -4439,6 +4439,9 @@ __git_ignore_line_inside_arguments () {
>
>  (( $+functions[_git_commands] )) ||
>  _git_commands () {
> +  local -a user_commands
> +  zstyle -a ":completion:${curcontext}:" user-commands user_commands || user_commands=()
> +
>   local -a main_porcelain_commands
>   main_porcelain_commands=(
>     add:'add file contents to index'
> @@ -4604,6 +4607,7 @@ _git_commands () {
>   _describe -t plumbing-sync-helper-commands 'plumbing sync helper command' plumbing_sync_helper_commands && ret=0
>   _describe -t plumbing-internal-helper-commands 'plumbing internal helper command' plumbing_internal_helper_commands && ret=0
>   _describe -t third-party-addons 'third party addon' _git_third_party && ret=0
> +  _describe -t user-specific-commands 'user specific command' user_commands && ret=0
>   return ret
>  }

Re: PATCH: (3/3) _git: re-add `user-commands' support again

[Frank Terbeck]

Nikolai Weibull wrote:
> Do we really need this style?  I don’t like it at all.  If the user
> wants to add completion for a sub-command they should really go the
> extra distance and add a proper completion definition for the whole
> sub-command.  It’s not hard to add a _git-subcommand file under
> ~/.zsh/functions (or similar) with a proper description and all.
>
> If you don’t disagree I’m going to remove it.

I know people who use this, yes. I don't use it myself, but that would
break backwards compatibility for them.

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

Re: PATCH: (3/3) _git: re-add `user-commands' support again

[Nikolai Weibull]

On Fri, Jul 22, 2011 at 14:00, Frank Terbeck <ft@bewatermyfriend.org> wrote:
> Nikolai Weibull wrote:
>> Do we really need this style?  I don’t like it at all.  If the user
>> wants to add completion for a sub-command they should really go the
>> extra distance and add a proper completion definition for the whole
>> sub-command.  It’s not hard to add a _git-subcommand file under
>> ~/.zsh/functions (or similar) with a proper description and all.
>>
>> If you don’t disagree I’m going to remove it.
>
> I know people who use this, yes. I don't use it myself, but that would
> break backwards compatibility for them.

Well, I’ve never guaranteed backwards compatibility in any of the
releases of _git.  It’s always been a work in progress.  The
user-commands style wasn’t something that I added, either.  Things are
stabilizing now, but that also means that I would like to cut cruft
like this.  Backwards compatibility isn’t in itself a strong enough
argument for keeping it around.

So, what exactly is the use case for user-commands?  Does it solve
something that something else won’t solve with greater satisfaction?

Re: PATCH: (3/3) _git: re-add `user-commands' support again

[Frank Terbeck]

Nikolai Weibull wrote:
[...]
> Well, I’ve never guaranteed backwards compatibility in any of the
> releases of _git.  It’s always been a work in progress.  The
> user-commands style wasn’t something that I added, either.  Things are
> stabilizing now, but that also means that I would like to cut cruft
> like this.  Backwards compatibility isn’t in itself a strong enough
> argument for keeping it around.
>
> So, what exactly is the use case for user-commands?  Does it solve
> something that something else won’t solve with greater satisfaction?

It solves the case mentioned in the comment on top of the file.

I don't say that there isn't a better way. Now there is, with the _git
completion add-ons. But I don't think we should break compatibility
unless we need to. And the code is simple enough and doesn't break
performance or impair usability. So I'd say just throwing it away
doesn't bring any advantages. But it would bring the disadvantage of
breaking existing working setups for no good reason.

So I'd be against removing it.

Regards, Frank

Re: PATCH: (3/3) _git: re-add `user-commands' support again

[Nikolai Weibull]

On Fri, Jul 22, 2011 at 14:49, Frank Terbeck <ft@bewatermyfriend.org> wrote:
> Nikolai Weibull wrote:
> [...]
>> Well, I’ve never guaranteed backwards compatibility in any of the
>> releases of _git.  It’s always been a work in progress.  The
>> user-commands style wasn’t something that I added, either.  Things are
>> stabilizing now, but that also means that I would like to cut cruft
>> like this.  Backwards compatibility isn’t in itself a strong enough
>> argument for keeping it around.
>>
>> So, what exactly is the use case for user-commands?  Does it solve
>> something that something else won’t solve with greater satisfaction?
>
> It solves the case mentioned in the comment on top of the file.
>
> I don't say that there isn't a better way. Now there is, with the _git
> completion add-ons. But I don't think we should break compatibility
> unless we need to. And the code is simple enough and doesn't break
> performance or impair usability. So I'd say just throwing it away
> doesn't bring any advantages. But it would bring the disadvantage of
> breaking existing working setups for no good reason.
>
> So I'd be against removing it.

OK, it stays for now.  I’m marking it as deprecated, however, and it
may be removed once we hit 5.0.

PATCH: (4/3) _git-buildpackage: use a #desc: line

[Frank Terbeck]

---

  If workers-29519 is applied, then this would make the already-existing
  `git-buildpackage' completion use a proper "#desc:" line, which could
  look like this:

zsh% git bu<tab>
- main porcelain command -
bundle        -- move objects and refs by archive
- third party addon -
buildpackage  -- build Debian packages from a git repository

  ...depending on a number of compsys-style, of course.


 Completion/Debian/Command/_git-buildpackage |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/Completion/Debian/Command/_git-buildpackage b/Completion/Debian/Command/_git-buildpackage
index 936539f..9351008 100644
--- a/Completion/Debian/Command/_git-buildpackage
+++ b/Completion/Debian/Command/_git-buildpackage
@@ -1,4 +1,5 @@
 #compdef git-buildpackage
+#desc:build Debian packages from a git repository
 
 _arguments \
   '--version[show program version number and exit]' \
-- 
1.7.6

Re: PATCH: (4/3) _git-buildpackage: use a #desc: line

[Nikolai Weibull]

On Wed, Jun 29, 2011 at 23:30, Frank Terbeck <ft@bewatermyfriend.org> wrote:

>  If workers-29519 is applied, then this would make the already-existing
>  `git-buildpackage' completion use a proper "#desc:" line, which could
>  look like this:

Does anyone have a better solution than this lying around?  I feel
that this should be set with a zstyle, but I can’t figure out how, for
example, _git-buildpackage would call zstyle when it’s only being
autoloaded.  Should _git, once loaded, load all autoloaded _git-*
functions so that they may set their description using zstyle?

Re: PATCH: (4/3) _git-buildpackage: use a #desc: line

[Frank Terbeck]

Nikolai Weibull wrote:
> On Wed, Jun 29, 2011 at 23:30, Frank Terbeck <ft@bewatermyfriend.org> wrote:
>
>>  If workers-29519 is applied, then this would make the already-existing
>>  `git-buildpackage' completion use a proper "#desc:" line, which could
>>  look like this:
>
> Does anyone have a better solution than this lying around?  I feel
> that this should be set with a zstyle, but I can’t figure out how, for
> example, _git-buildpackage would call zstyle when it’s only being
> autoloaded.  Should _git, once loaded, load all autoloaded _git-*
> functions so that they may set their description using zstyle?

Actually, I don't think this is something styles are right for. There's
no context sensitivity required, nor is there anything that needs to be
configured.

This is very much like `compinit' looking at the first line of _* files
from $fpath. That's probably not what all completions should be doing,
but _git isn't quite the common completion either. And this solution is
pretty straight forward.  So, unless there's some corner case I am
missing, I don't see why it should be changed to something that's (as I
pointed out earlier) less suited.

Regards, Frank

Re: PATCH: (4/3) _git-buildpackage: use a #desc: line

[Nikolai Weibull]

On Wed, Jul 20, 2011 at 20:22, Frank Terbeck <ft@bewatermyfriend.org> wrote:
> Nikolai Weibull wrote:
>> On Wed, Jun 29, 2011 at 23:30, Frank Terbeck <ft@bewatermyfriend.org> wrote:
>>
>>>  If workers-29519 is applied, then this would make the already-existing
>>>  `git-buildpackage' completion use a proper "#desc:" line, which could
>>>  look like this:
>>
>> Does anyone have a better solution than this lying around?  I feel
>> that this should be set with a zstyle, but I can’t figure out how, for
>> example, _git-buildpackage would call zstyle when it’s only being
>> autoloaded.  Should _git, once loaded, load all autoloaded _git-*
>> functions so that they may set their description using zstyle?
>
> Actually, I don't think this is something styles are right for. There's
> no context sensitivity required, nor is there anything that needs to be
> configured.
>
> This is very much like `compinit' looking at the first line of _* files
> from $fpath. That's probably not what all completions should be doing,
> but _git isn't quite the common completion either. And this solution is
> pretty straight forward.  So, unless there's some corner case I am
> missing, I don't see why it should be changed to something that's (as I
> pointed out earlier) less suited.

Hm, OK, perhaps you’re right.  I still don’t like it, but I’ll live
with it.  I will, however, change this to be “#description ” instead
of the slightly cryptic “#desc:”.  “#Description ” reads better with
the “#compdef ” on line one.  I hope this change is OK with you.

Re: PATCH: (4/3) _git-buildpackage: use a #desc: line

[Frank Terbeck]

Nikolai Weibull wrote:
> On Wed, Jul 20, 2011 at 20:22, Frank Terbeck <ft@bewatermyfriend.org> wrote:
[...]
> Hm, OK, perhaps you’re right.  I still don’t like it, but I’ll live
> with it.  I will, however, change this to be “#description ” instead
> of the slightly cryptic “#desc:”.  “#Description ” reads better with
> the “#compdef ” on line one.  I hope this change is OK with you.

Sounds reasonable.

Regards, Frank

PATCH: (5/3) _git: Make file-completion fallback optional

[Frank Terbeck]

Jonas asserted that not everyone may like _git to fall back to file name
completion for sub-commands it doesn't know. This makes that behaviour
configurable. See the comment on top of _git for details.

The default is to *use* the fallbacke, since I am convinced that is the
least surprising way to do handle these situations. But if you really
dislike the fallback, now you can have it your way. With an indicator as
to *why* nothing is being completed even.
---
 Completion/Unix/Command/_git |   14 +++++++++++++-
 1 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index a1856df..3fa1a73 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -17,6 +17,16 @@
 #
 # You could even create a function _git-foo() to handle specific completion
 # for that command.
+#
+# When git does not know a given sub-command (say `bar'), it falls back to
+# completing file names for all arguments to that sub command. I.e.:
+#
+#     % git bar <tab>
+#
+# ...will complete file names. If you do *not* want that fallback to be used,
+# use the `use-fallback' style like this:
+#
+#     % zstyle ':completion:*:*:git*:*' use-fallback false
 
 # TODO: There is still undocumented configurability in here.
 
@@ -6035,9 +6045,11 @@ _git() {
 
         if (( ${+functions[_git-$words[1]]} )); then
             _git-$words[1]
-        else
+        elif zstyle -T ":completion:${curcontext}:" use-fallback; then
             _path_files
             ret=$?
+        else
+            _message 'Unknown sub-command'
         fi
         ;;
     esac
-- 
1.7.6

Re: PATCH: (5/3) _git: Make file-completion fallback optional

[Nikolai Weibull]

2011/6/30 Frank Terbeck <ft@bewatermyfriend.org>:
> Jonas asserted that not everyone may like _git to fall back to file name
> completion for sub-commands it doesn't know. This makes that behaviour
> configurable. See the comment on top of _git for details.
>
> The default is to *use* the fallbacke, since I am convinced that is the
> least surprising way to do handle these situations. But if you really
> dislike the fallback, now you can have it your way. With an indicator as
> to *why* nothing is being completed even.

I don’t think we should do it this way.  If a user doesn’t want files
to be completed, they should be disabling it with a zstyle.  I can’t
figure out how you do that best, but one way seems to be

zstyle ':completion:*:*:git-mysubcommand:*' file-patterns ''

That won’t display a message, though.

Re: PATCH: (5/3) _git: Make file-completion fallback optional

[Nikolai Weibull]

2011/7/22 Nikolai Weibull <now@bitwi.se>:
> 2011/6/30 Frank Terbeck <ft@bewatermyfriend.org>:
>> Jonas asserted that not everyone may like _git to fall back to file name
>> completion for sub-commands it doesn't know. This makes that behaviour
>> configurable. See the comment on top of _git for details.
>>
>> The default is to *use* the fallbacke, since I am convinced that is the
>> least surprising way to do handle these situations. But if you really
>> dislike the fallback, now you can have it your way. With an indicator as
>> to *why* nothing is being completed even.

> I don’t think we should do it this way.  If a user doesn’t want files
> to be completed, they should be disabling it with a zstyle.  I can’t
> figure out how you do that best, but one way seems to be
>
> zstyle ':completion:*:*:git-mysubcommand:*' file-patterns ''
>
> That won’t display a message, though.

Does anyone have any better way of dealing with this?