PATCH: git --pretty completion, and (new) completion for npm

PATCH: git --pretty completion, and (new) completion for npm

[Johan Sundström]

[-- Attachment #1.1: Type: text/plain, Size: 793 bytes --]

I just realized I have been using zsh for about fifteen years, and that the
sane(r) completion system of zsh 3.1 has been around for more than ten. Both
together must have saved me months of work and typing on aggregate, by
now. Time for some celebration! :-)

I took to adding documented completion for to the git completer for syntax
that is impossible to remember and hard to find in the man page; git log
--pretty (and whichever other commands support --pretty / --format) now
covers the whole lot except %w, which seemed like it would need a whole
little state machine in itself.

Also, a Completion/Unix/Command/_npm (the node package manager) completer
that delegates entirely to npm's built-in support.

Cheers!

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

[-- Attachment #1.2: Type: text/html, Size: 929 bytes --]

[-- Attachment #2: _git-pretty.patch --]
[-- Type: application/octet-stream, Size: 5036 bytes --]

From 50fe32aa4cdffad0054a6b8cb058b1d2e5361d2b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Johan=20Sundstr=C3=B6m?= <oyasumi@gmail.com>
Date: Sun, 13 Mar 2011 13:10:03 -0700
Subject: [PATCH 1/2] make git --pretty completion list git config pretty.NAME defs, and all fields but %w

---
 Completion/Unix/Command/_git |   85 ++++++++++++++++++++++++++++++++++++++----
 1 files changed, 77 insertions(+), 8 deletions(-)

diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index bf22a3c..ca1dd5d 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -5543,23 +5543,92 @@ __git_setup_diff_options () {
     '--output[undocumented]:undocumented')
 }
 
+(( $+functions[__git_setup_pretty_aliases] )) ||
+__git_setup_pretty_aliases () {
+  local spec name pfmt IFS=$'\n'
+  local -a aliases
+  aliases=()
+  for spec in $(git config --get-regexp '^pretty\.' 2>/dev/null); do
+    name="${${spec#pretty.}/ */}"
+    pfmt="${spec#pretty.$name }"
+    pfmt="$(sed 's_\([]:["]\)_\\\1_g' <<<"$pfmt")" # escapes ], :, [, and "
+    aliases+=(${name}'\:"git config alias for\: '${pfmt}'"')
+  done
+  pretty_aliases="${(pj:\n:)aliases}"
+}
+
+(( $+functions[__git_setup_pretty_options] )) ||
+__git_setup_pretty_options () {
+  local main fmts
+  main='oneline\:"commit-ids and subject of messages"
+        short\:"few headers and only subject of messages"
+        medium\:"most parts of messages"
+        full\:"all parts of commit messages"
+        fuller\:"like full and includes dates"
+        email\:"use email headers like From and Subject"
+        raw\:"the raw commits"
+        format\:"specify own format"
+        '
+  __git_setup_pretty_aliases
+  fmts='
+    %H\:"commit hash"
+    %h\:"abbreviated commit hash"
+    %T\:"tree hash"
+    %t\:"abbreviated tree hash"
+    %P\:"parent hashes"
+    %p\:"abbreviated parent hashes"
+    %an\:"author name"
+    %aN\:"author name (respecting .mailmap)"
+    %ae\:"author email"
+    %aE\:"author email (respecting .mailmap)"
+    %ad\:"author date (format respects --date= option)"
+    %aD\:"author date, RFC2822 style"
+    %ar\:"author date, relative"
+    %at\:"author date, UNIX timestamp"
+    %ai\:"author date, ISO 8601 format"
+    %cn\:"committer name"
+    %cN\:"committer name (respecting .mailmap)"
+    %ce\:"committer email"
+    %cE\:"committer email (respecting .mailmap)"
+    %cd\:"committer date"
+    %cD\:"committer date, RFC2822 style"
+    %cr\:"committer date, relative"
+    %ct\:"committer date, UNIX timestamp"
+    %ci\:"committer date, ISO 8601 format"
+    %d\:"ref names, like the --decorate option of git-log(1)"
+    %e\:"encoding"
+    %s\:"subject"
+    %f\:"sanitized subject line, suitable for a filename"
+    %b\:"body"
+    %B\:"raw body (unwrapped subject and body)"
+    %N\:"commit notes"
+    %gD\:"reflog selector, e.g., refs/stash@{1}"
+    %gd\:"shortened reflog selector, e.g., stash@{1}"
+    %gs\:"reflog subject"
+    %Cred\:"switch color to red"
+    %Cgreen\:"switch color to green"
+    %Cblue\:"switch color to blue"
+    %Creset\:"reset color"
+    %C(...)\:"color specification, as described in color.branch.* config option"
+    %m\:"left, right or boundary mark"
+    %n\:"newline"
+    %%\:"a raw %"
+    %x00\:"print a byte from a hex code"'
+  pretty_options='[pretty print commit messages]::format:(('${main}${pretty_aliases}${fmts}'))'
+}
+
+
 (( $+functions[__git_setup_revision_options] )) ||
 __git_setup_revision_options () {
   local -a diff_options
   __git_setup_diff_options
+  __git_setup_pretty_options
 
   revision_options=(
     $diff_options
     # TODO: format pretty print format is a lot more advanced than this.
     # TODO: You can’t actually specify --format without a format.
-    '(-v --header)'{--pretty=-,--format=-}'[pretty print commit messages]::format:((oneline\:"commit-ids and subject of messages"
-                                                                                    short\:"few headers and only subject of messages"
-                                                                                    medium\:"most parts of messages"
-                                                                                    full\:"all parts of commit messages"
-                                                                                    fuller\:"like full and includes dates"
-                                                                                    email\:"use email headers like From and Subject"
-                                                                                    raw\:"the raw commits"
-                                                                                    format\:"specify own format"))'
+    '(-v --header)'{--pretty=-,--format=-}${pretty_options}
     '--abbrev-commit[show only partial prefixes of commit object names]'
     '--oneline[shorthand for --pretty=oneline --abbrev-commit]'
     '--encoding=-[output log messages in given encoding]:: :__git_encodings'
-- 
1.7.4.1


[-- Attachment #3: _npm --]
[-- Type: application/octet-stream, Size: 529 bytes --]

#compdef npm

# Node Package Manager 0.3.15 completion, letting npm do all the completion work

_npm() {
  compadd -- $(_npm_complete $words)
}

# We want to show all errors of any substance, but never the "npm (not )ok" one.
# (Also doesn't consider "ERR! no match found" worth breaking the terminal for.)
_npm_complete() {
  local ask_npm
  ask_npm=(npm completion --color false --loglevel error -- $@)
  { _call_program npm $ask_npm 2>&1 >&3 \
  | egrep -v '^(npm (not |)ok|ERR! no match found)$' >&2; \
  } 3>&1
}

_npm "$@"

Re: PATCH: git --pretty completion, and (new) completion for npm

[Frank Terbeck]

Johan Sundström wrote:
[...]
> I took to adding documented completion for to the git completer for syntax that
> is impossible to remember and hard to find in the man page; git log --pretty
> (and whichever other commands support --pretty / --format) now covers the whole
> lot except %w, which seemed like it would need a whole little state machine in
> itself.

Hm. This only works for stuff directly after the `=', doesn't it? As in:

% git log -1 --pretty=%<tab>

But not in:

% git log -1 --pretty="%H %<tab>

That would be pretty useful, don't you think? 

Also, you can cancel out the use of sed(1) from the code:

diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index d65362e..ef4f263 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -5550,8 +5550,7 @@ __git_setup_pretty_aliases () {
   aliases=()
   for spec in $(git config --get-regexp '^pretty\.' 2>/dev/null); do
     name="${${spec#pretty.}/ */}"
-    pfmt="${spec#pretty.$name }"
-    pfmt="$(sed 's_\([]:["]\)_\\\1_g' <<<"$pfmt")" # escapes ], :, [, and "
+    pfmt="${${spec#pretty.$name }//(#b)([]:[\"])/\\\\${match[1]}}"
     aliases+=(${name}'\:"git config alias for\: '${pfmt}'"')
   done
   pretty_aliases="${(pj:\n:)aliases}"

...which would save a fork().

Regards, Frank

PS: I've just committed the _npm completion from the message I'm
    replying to.

-- 
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: git --pretty completion, and (new) completion for npm

[Johan Sundström]

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

On Sun, Mar 20, 2011 at 03:35, Frank Terbeck <ft@bewatermyfriend.org> wrote:

> Johan Sundström wrote:
> [...]
> > I took to adding documented completion for to the git completer for
> syntax that
> > is impossible to remember and hard to find in the man page; git log
> --pretty
> > (and whichever other commands support --pretty / --format) now covers the
> whole
> > lot except %w, which seemed like it would need a whole little state
> machine in
> > itself.
>
> Hm. This only works for stuff directly after the `=', doesn't it? As in:
>
> % git log -1 --pretty=%<tab>
>

Correct; enough to document what the properties are when there's just the
one you're interested in (for me it's usually %H for the commit hash), but
sub-ideal for longer formats.

But not in:
>
> % git log -1 --pretty="%H %<tab>
>
> That would be pretty useful, don't you think?
>

It certainly would, but I fear my completion beard is not quite long enough
yet for me to pull off that state machine, myself. :-)

If someone is up for that, it might also be worth adding the %w flag which
takes one or two numeric arguments while at it, with correct syntax looking
like either of these:

  %w(integer_width)
  %w(integer_width,integer_indent_first_line)
  %w(integer_width,integer_indent_first_line,integer_indent_subsequent_lines)

Full documentation, as resolved after cross-referencing the right excerpts
of the right sections of "man git log" and "man git short-log" and testing
to verify that it's correct (and fixing the defaults, that turned out to be
different for git log):

  %w(<width>[,<indent1>[,<indent2>]])

Linewrap the output by wrapping each line at width. The first line of each
entry is indented by indent1 spaces, and the second and subsequent lines are
indented by indent2 spaces.  indent1, and indent2 both default to 0.

I'm not entirely sure how a good completion for %w would operate to convey
some of that, though. Not specified anywhere, but found by testing: the
wrapping applies to the %s and %b formats only (commit message subject and
body lines).

Also, you can cancel out the use of sed(1) from the code:


> diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
> index d65362e..ef4f263 100644
> --- a/Completion/Unix/Command/_git
> +++ b/Completion/Unix/Command/_git
> @@ -5550,8 +5550,7 @@ __git_setup_pretty_aliases () {
>   aliases=()
>   for spec in $(git config --get-regexp '^pretty\.' 2>/dev/null); do
>     name="${${spec#pretty.}/ */}"
> -    pfmt="${spec#pretty.$name }"
> -    pfmt="$(sed 's_\([]:["]\)_\\\1_g' <<<"$pfmt")" # escapes ], :, [, and
> "
> +    pfmt="${${spec#pretty.$name }//(#b)([]:[\"])/\\\\${match[1]}}"
>     aliases+=(${name}'\:"git config alias for\: '${pfmt}'"')
>   done
>   pretty_aliases="${(pj:\n:)aliases}"
>
> ...which would save a fork().
>

Ah, that's what it looks like! I tried for a bit, but failed. For that
amount of magic, I'd say it's fair to keep the comment; what the line
accomplishes doesn't quite jump out at you, and if there's need of debugging
(or other changes) later, it's good to know the current/prior intent.

Regards, Frank
>
> PS: I've just committed the _npm completion from the message I'm
>    replying to.
>

Thanks!

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

Re: PATCH: git --pretty completion, and (new) completion for npm

[Nikolai Weibull]

2011/3/20 Johan Sundström <oyasumi@gmail.com>:
> On Sun, Mar 20, 2011 at 03:35, Frank Terbeck <ft@bewatermyfriend.org> wrote:
>> Johan Sundström wrote:
>> > I took to adding documented completion for to the git completer for
>> syntax that
>> > is impossible to remember and hard to find in the man page; git log
>> --pretty
>> > (and whichever other commands support --pretty / --format) now covers the
>> whole
>> > lot except %w, which seemed like it would need a whole little state
>> machine in
>> > itself.

>> Hm. This only works for stuff directly after the `=', doesn't it? As in:
>>
>> % git log -1 --pretty=%<tab>

> Correct; enough to document what the properties are when there's just the
> one you're interested in (for me it's usually %H for the commit hash), but
> sub-ideal for longer formats.
>
> But not in:
>>
>> % git log -1 --pretty="%H %<tab>
>>
>> That would be pretty useful, don't you think?

> It certainly would, but I fear my completion beard is not quite long enough
> yet for me to pull off that state machine, myself. :-)

This was never applied.  Is anyone interested in having this added?
If so, it should be cleaned up and should probably add proper %w
handling and multiple-item handling.

Re: PATCH: git --pretty completion, and (new) completion for npm

[Mikael Magnusson]

2011/8/3 Nikolai Weibull <now@bitwi.se>:
> 2011/3/20 Johan Sundström <oyasumi@gmail.com>:
>> On Sun, Mar 20, 2011 at 03:35, Frank Terbeck <ft@bewatermyfriend.org> wrote:
>>> Johan Sundström wrote:
>>> > I took to adding documented completion for to the git completer for
>>> syntax that
>>> > is impossible to remember and hard to find in the man page; git log
>>> --pretty
>>> > (and whichever other commands support --pretty / --format) now covers the
>>> whole
>>> > lot except %w, which seemed like it would need a whole little state
>>> machine in
>>> > itself.
>
>>> Hm. This only works for stuff directly after the `=', doesn't it? As in:
>>>
>>> % git log -1 --pretty=%<tab>
>
>> Correct; enough to document what the properties are when there's just the
>> one you're interested in (for me it's usually %H for the commit hash), but
>> sub-ideal for longer formats.
>>
>> But not in:
>>>
>>> % git log -1 --pretty="%H %<tab>
>>>
>>> That would be pretty useful, don't you think?
>
>> It certainly would, but I fear my completion beard is not quite long enough
>> yet for me to pull off that state machine, myself. :-)
>
> This was never applied.  Is anyone interested in having this added?
> If so, it should be cleaned up and should probably add proper %w
> handling and multiple-item handling.
>

Not sure if this helps you,
http://www.zsh.org/mla/workers/2011/msg00861.html but it also
completes a bunch of %stuff after an assignment, so it seems similar.

-- 
Mikael Magnusson

Re: PATCH: git --pretty completion, and (new) completion for npm

[Nikolai Weibull]

On Wed, Aug 3, 2011 at 17:05, Mikael Magnusson <mikachu@gmail.com> wrote:
> 2011/8/3 Nikolai Weibull <now@bitwi.se>:
>> 2011/3/20 Johan Sundström <oyasumi@gmail.com>:
>>> On Sun, Mar 20, 2011 at 03:35, Frank Terbeck <ft@bewatermyfriend.org> wrote:
>>>> Johan Sundström wrote:
>>>> > I took to adding documented completion for to the git completer for
>>>> syntax that
>>>> > is impossible to remember and hard to find in the man page; git log
>>>> --pretty
>>>> > (and whichever other commands support --pretty / --format) now covers the
>>>> whole
>>>> > lot except %w, which seemed like it would need a whole little state
>>>> machine in
>>>> > itself.
>>
>>>> Hm. This only works for stuff directly after the `=', doesn't it? As in:
>>>>
>>>> % git log -1 --pretty=%<tab>
>>
>>> Correct; enough to document what the properties are when there's just the
>>> one you're interested in (for me it's usually %H for the commit hash), but
>>> sub-ideal for longer formats.
>>>
>>> But not in:
>>>>
>>>> % git log -1 --pretty="%H %<tab>
>>>>
>>>> That would be pretty useful, don't you think?
>>
>>> It certainly would, but I fear my completion beard is not quite long enough
>>> yet for me to pull off that state machine, myself. :-)
>>
>> This was never applied.  Is anyone interested in having this added?
>> If so, it should be cleaned up and should probably add proper %w
>> handling and multiple-item handling.

> Not sure if this helps you,
> http://www.zsh.org/mla/workers/2011/msg00861.html but it also
> completes a bunch of %stuff after an assignment, so it seems similar.

Thanks, though I think I have a grip on how it should be done (I do
something similar already in parts of the git-config completion, I
believe).  I was, however, hoping that someone else would take a look
and do it :-).