ZSH completions

[keith]

From this recommendation it would be nice, probably even possible, to setup some generation for CocoaPods zsh completions. Here is the homebrew completion library, as you can see you can do pretty much anything in them, including piping output from other commands to the completion list.

I would gladly write this setup. I think that it could be built dynamically at least to the extent of the commands and flags assuming we could track those down somewhere. The homebrew completion also completes things like brew install gi<tab> by searching all formula to this:

Although I'm not sure I can think of a place for this.

[alloy]

I can imagine a CLI option such as --dump-zsh-completion to iterate over all commands and dump the info into a zsh-completion template or something.

[alloy]

Or --dump-shell-completion=zsh and then later add e.g. fish ;)

[fabiopelosin]

@alloy currently we don't have support for options arguments... correct?

[fabiopelosin]

I like the idea of the option but I think that it should be hidden... no? An why a flag instead of a proper sub command?

[alloy]

currently we don't have support for options arguments... correct?

Yeah we do, see https://github.com/CocoaPods/CLAide/blob/master/examples/argv.rb#L12

I like the idea of the option but I think that it should be hidden... no? An why a flag instead of a proper sub command?

Yeah it would not be exposed in any help banners. Indeed, a hidden command might be more appropriate.

[keith]

I think the shell agnostic approach is definitely the better one there. The generation could also default to the current $SHELL

[keith]

As long as those arguments could be automated out by subcommand I don't think it would be that bad to automate.

[alloy]

The generation could also default to the current $SHELL

Very good point!

As long as those arguments could be automated out by subcommand I don't think it would be that bad to automate.

A command is only ever available on one nesting level… which now makes me think that a command wouldn’t work, as a program might define an arbitrary level of subclasses of the main Command class, so we cannot know where to install that command.

[alloy]

(Where those “subclasses” would be abstract commands, so not visible/callable.)

[keith]

In the case of CocoaPods the commands each seem to inherit from the Command class right? Where they could inherit directly from CLAide::Command if they wanted to?

[alloy]

In CocoaPods, we define one base class, which is the one you mean by Command (to be pedantic, it’s called Pod::Command) and inherits from CLAide::Command. Our base class is marked as being ‘abstract’ and all other command classes inherit from that abstract base class.

So in this scenario, defining a default command such as dump-shell-completion on the CLAide::Command class wouldn’t work, iirc.

[keith]

Right that does make that more complicated. The easy option here is for me to simply write the file for CocoaPods 😜

[alloy]

The easy option would be to just use an option for now as per my original reply :D

[keith]

But which subclasses would you pull from?

[alloy]

What you do is that you start at the root class CLAide::Command and then recursively iterate over the callable subcommands.

[keith]

And you're thinking we should add this functionality to CLAide itself?

[fabiopelosin]

This comment is outside the scope of this issue but default commands should be available in CLAide (for example version, and help).

[alloy]

And you're thinking we should add this functionality to CLAide itself?

Aye. It would be equally helpful to others, e.g. RubyMotion.

[alloy]

This comment is outside the scope of this issue but default commands should be available in CLAide (for example version, and help).

The version and help things are almost always options (in other CLI programs), not commands, so I don’t think we should diverge from that.

[fabiopelosin]

The version and help things are almost always options (in other CLI programs), not commands, so I don’t think we should diverge from that.

From a quick check it looks that many commands accept both variants. However I can live with them as option... now that I recall my issue was with not having --version implemented by default... in detail with having to do this

[fabiopelosin]

Bower implementation: http://bower.io/#completion-experimental