Putting options after tasks

Putting options after tasks

[Jesper Nygårds]

I am trying to write a completion function for gradle, and face some
problems regarding the order of options and tasks.

Below I have simplified my approach as much as possible, in order to
explain my problem clearly. The basis for this is originally the
gradle completion from oh-my-zsh.

gradle can take any number of options (long options starting with
"--") and tasks (with no prefix). In my example below, I have boiled
this down to two options ("--info" and "--stacktrace"), and two tasks
("build" and "clean").

These options and tasks can come in any order, so the following
command lines would all be valid:
gradle clean build
gradle --info clean build --stacktrace
gradle --stacktrace --info clean build
etc

My problem is this: the completion below works fine and completes both
options and tasks, but once I have at least one task on the command
line, it no longer completes for options. So, for example, if I have
"gradle build --i" and press <tab>, I get no suggestions, whereas
"gradle bu<tab>" gives "gradle build", and "gradle --i<tab>" gives
"gradle --info".

What do I have to do to make it possible to complete options after tasks?

_gradle() {
    local ret=1 state
    local curcontext="$curcontext"

    _arguments -C \
        '--info[Log at the info level]' \
        '--stacktrace[Display stacktrace on error]' \
        '*::command:->command' \
        && ret=0

    if [[ -n $state ]]; then
        commands=( "clean:Clean the project" "build:Build the project" )
        _describe -t commands 'gradle commands' commands && ret=0
    fi

    return $ret
}

compdef _gradle gradle

Re: Putting options after tasks

[Bart Schaefer]

On Mar 14,  9:53am, Jesper Nygårds wrote:
}
} What do I have to do to make it possible to complete options after tasks?

_arguments is designed to assume that programs accept all options first
and all other arguments after them.  If you have a program that doesn't
follow that convention, you may be able to use _regex_arguments (good
luck there, I'm not sure there's anyone still reading this list who has
any experience with it) or will need to write your own loop over the
$words array.

Given that the tasks and options can be freely mixed in this way, I
presume that none of the options take a following argument (that is,
"--foobar zoom" never means that "zoom" must appear immediately after
"--foobar").

If that's true, then one possibility is to make a first loop over the
$words array and insert a "+" sign in front of all the task names (but
stop before, or skip over, $words[CURRENT]), so that _arguments can
interpret as options the words you are NOT completing.  In that same
loop over the words, build up a a list of dummy option specs to pass
to _arguments so it knows to skip them.  Then add those dummy specs to
the real specs when making the _arguments call.

At the end, loop over $words again and remove the "+" signs you added
before returning $ret.  This may not be necessary but will avoid conflict
with other completers later.

Re: Putting options after tasks

[Jesper Nygårds]

On Wed, Mar 14, 2012 at 6:19 PM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
> _arguments is designed to assume that programs accept all options first
> and all other arguments after them.

Naive question: why? It seems to be a great deal of programs can take
their options at any position nowadays.

> Given that the tasks and options can be freely mixed in this way, I
> presume that none of the options take a following argument (that is,
> "--foobar zoom" never means that "zoom" must appear immediately after
> "--foobar").

No, unfortunately that's not true, only my simplified example gave
that impression. In reality, some of the options can take a following
argument.

> If that's true, then one possibility...

Thank you very much for this, Bart. Since Mikael has reported that it
seems to work going down the _arguments route, I'll have a go at that,
and see if it works also when I expand my example to the real set of
options. I'll report back if I run into trouble.

Re: Putting options after tasks

[Mikael Magnusson]

2012/3/14 Jesper Nygårds <jesper.nygards@gmail.com>:
> I am trying to write a completion function for gradle, and face some
> problems regarding the order of options and tasks.
>
> Below I have simplified my approach as much as possible, in order to
> explain my problem clearly. The basis for this is originally the
> gradle completion from oh-my-zsh.
>
> gradle can take any number of options (long options starting with
> "--") and tasks (with no prefix). In my example below, I have boiled
> this down to two options ("--info" and "--stacktrace"), and two tasks
> ("build" and "clean").
>
> These options and tasks can come in any order, so the following
> command lines would all be valid:
> gradle clean build
> gradle --info clean build --stacktrace
> gradle --stacktrace --info clean build
> etc
>
> My problem is this: the completion below works fine and completes both
> options and tasks, but once I have at least one task on the command
> line, it no longer completes for options. So, for example, if I have
> "gradle build --i" and press <tab>, I get no suggestions, whereas
> "gradle bu<tab>" gives "gradle build", and "gradle --i<tab>" gives
> "gradle --info".
>
> What do I have to do to make it possible to complete options after tasks?

Replace :: with : and it will "work", however there are some other
problems with the code you wrote. You modify the $commands array
without making it local, you also forget to local a few other things.
The following seems to work fine (i also put it in an autoloaded
_gradle file in $fpath):


#compdef gradle

local ret=1 state state_descr line
local curcontext="$curcontext"
local -A opt_args
local -a commands

_arguments -C \
   '--info[Log at the info level]' \
   '--stacktrace[Display stacktrace on error]' \
   '*:command:->command' \
   && ret=0

if [[ $state == command ]]; then
   commands=( "clean:Clean the project" "build:Build the project" )
   _describe -t commands 'gradle commands' commands && ret=0
fi

return ret

-- 
Mikael Magnusson

Re: Putting options after tasks

[Jesper Nygårds]

2012/3/14 Mikael Magnusson <mikachu@gmail.com>:
> Replace :: with : and it will "work", however there are some other
> problems with the code you wrote....

Thank you very much for the feedback, Mikael! I'll try this out.

Jesper