Completion fails to run if options are passed with the command

[coryroloff]

Completion callbacks fail to run if options are passed with the command.

For example, if you have the command: "test -p PROJECTKEY cmdName"

With a completion set for the command "cmdName," the completion handler will not be called if you also set the "-p" option.

It looks like you're using another library of yours to parse the COMP_LINE input to determine which command is set. Do you think there's a way to tie in with Commander's parsing?

Nothing against your approach, I'm just thinking if there's a way to use Commander's parsing, then this would work even as they add features.

Let me know if I can help.

Thanks!

[twolfson]

Ah, good catch. I will take a look at this by the end of the weekend. Thanks for the report =)

[coryroloff]

Awesome! Thanks!

[twolfson]

Sorry for the delay on this. I am bouncing back and forth on whether options should be baked into completion (change structure to be more XML-like)

{
  value: 'git',
  children: [{
    value: '-p',
    optional: true
  }, {
    value: 'checkout'
  }]
}

or if we should expose an API for completing against a subtree (e.g. this.complete).

I am leaning against the latter because option handling can vary so much between CLIs (e.g. option with multiple values following it, option must come before a given parameter). I will update you if I start to go down a specific venue.

[twolfson]

Alright, going to try out this.complete tonight.

[twolfson]

I have made progress but it isn't yet complete. The current plan is:

• Move completion to a recursive solution with subtrees to complete against
• Allow using this.complete against current subtree (e.g. set -p on same layer as checkout)
• Allow adding/removing completed words via subtree methods in preparation for this.complete recursion (e.g. --dir <cwd>)

[twolfson]

I have successfully built recursion inside of completion. I should have option support inside of commander-completion by the end of tomorrow.

[twolfson]

Ugh, thought I had a solution but I do not. I am going back to the drawing board. The problem was that I attempted to define options at the same level of commands (as if they were commands themself). However, that does not work (and I am not sure it was actually a proper use case at all).

{
  git: {
    '-b': function (info, cb) {
      // Recurse back into ourself
      return this.parentNode.complete(info, cb);
    },
    checkout: function (info, cb) {
       // Resolve git branches
    }
  }
}

We need a way to support the following:

git checkout -b hello|
git checkout -b hello| --more-options
git -b checkout hello| # I am not sure this will ever be valid but we should consider what it means/how we could support it

[twolfson]

Alright, I have sorted everything out with a new data structure which is significantly more verbose but should support everything.

There are now working tests against options in completion and commander-completion in my working branches. I will land, document, and release them by the end of next weekend.

Sorry for the delay on this, I really lacked foresight on this topic o_o

[twolfson]

Alright, this is finally resolved. I have completed and landed the feature in 0.4.0. Thanks for the issue! =)