Tab Completion of "repo" using Github API

[Amar1729]

So I wanted to be able to use gitit to open any repo but hated having to cd somewhere or try to remember another person's username and full git repo name. I've started mocking up very simple tab completion for the gitit repo subcommand - initial work is here.

I'm new to zsh tab completion so the style is really bad and needs to be cleaned a lot before a possible PR.

Currently, it:

1. completes ONLY the command repo (I'll add the other commands soon?)
2. waits for you to type out a username, or completes usernames from a cache file
3. once you complete a username, it checks the cache file - if it's too old or the user isn't there, it pulls from the GitHub API (and caches the results).

Usage:

$ gitit r<TAB>
$ gitit repo

$ gitit repo peterhurford <TAB>    # note the space - this signifies a complete username
$ gitit repo peterhurford 
64or32                        loRem                         shellplyr
DMatrix.hs                    looker-lendingclub            shinyview
...

# once a user's repos have been cached, you can then tab-complete that username
$ gitit repo pet<TAB>
$ gitit repo peterhurford 
...

This is completely up to you as the author, but I'm not sure if you feel this is scope or not? There are a few problems with the current form:

• (major) adds a shell dependency on the jq tool (this line), which I use for parsing the JSON return. This could possibly be replaced with sed or the like since we're looking for a very specific field in the JSON. Of course, completion for repo could just fail gracefully if jq isn't installed, and other commands would complete fine.
• (minor) is it depends on the public GitHub API, which is rate-limited at 60/hour, so if you go crazy trying to poll all your favorite authors from GitHub initially it'll start failing out (currently with incomprehensible messages)
• (minor) the API only returns at max 100 results at a time. The API includes a sort param for most recently updated, but if you're polling a user with more than 100 repos and looking for an old one, it currently won't show up in the results.
• (minor) adds a little bit of overhead to tab completion for the repo command

Relevant to #8 and possibly #19 .

[peterhurford]

Hi @Amar1729. I don't know anything about zsh tab completion but I would love to get this into the repo if possible. It looks like an amazing feature to have. I don't think the jq extension is too burdensome.

Cleaning up error messages from the GitHub API could be useful. I don't see the 100 repo limit as being a huge issue. I also don't think the overhead of tab completion will be a big problem and I think people would roughly know what to expect.

Do you know if this change would keep the plugin compatible with non-zsh operating systems? I'm okay going zsh-only for an awesome feature like this but I'd like to keep compatibility if possible.

[Amar1729]

Cool cool, I'll keep working on it!

The completions are completely encapsulated in the _gitit file - and as per the README installation for bash is just done by downloading the git-it-on.zsh file - so the plugin will still work on bash systems. I can double-check this before submitting a PR.

[Amar1729]

One question, since I'm almost done with the completions.

I've been working on adding tab completion of pull requests by number (here and here).

Looks like:

$ gitit pulls <TAB>
100  -- (open) Description of pull
300  -- (open) Description of pull

One potential issue is that gitit pulls also allows opening the page for closed issues by number, and it accepts filters to open a search page for PRs. So this tab completion might look restrictive in that it doesn't offer all possible candidates for completion and users may forget about the full functionality.

Would you like the candidates for gitit pulls to be consistent and offer everything possible (i.e. all open+closed PR numbers and list of possible filters), some combination of those, or nothing at all?

One thing to note is that completion for filters - while it wouldn't be too difficult - could end up looking visually messy. Possibly similar issue if we should display all open+closed PRs.

[dcnieho]

Super cool! Did you ever work further on it?