> I would say '-a' should only be evaluated if:
> 1: If defined with '-s' or '-l', only when completing that specific
> option.
> 2: If not defined with '-s' or '-l' in all cases when not completing a
> option '-' or an argument to an option (where such argument is required).
I agree.
And if some
On Fri, Apr 13, 2012 at 3:47 PM, Maxim Gonchar wrote:
> I can definitely see the benefit of using it that way, however I think its
>> incorrect, and just exploiting a flaw in the complete command.
>>
> If you run 'complete --help' and check examples you will see the usage of
> command arguments w
On Fri, Apr 13, 2012 at 10:46 AM, Maxim Gonchar wrote:
> So it is intentional then. How can I prevent this behaviour? I toyed with
>> __fish_contains_opt, but that is not optimal. I will try to parse
>> commandline --current-token but it gets too complicated, it defies the
>> simplicity of comple
On Fri, Apr 13, 2012 at 5:01 PM, SanskritFritz wrote:
>
> On Fri, Apr 13, 2012 at 3:47 PM, Maxim Gonchar wrote:
>
>> And everything that should be done for it is to stop fish calling '-a'
>> script when calling completion of 'cmd -'. Just like Sanskrit Fritz have
>> written in first message.
>>
>
On Fri, Apr 13, 2012 at 3:47 PM, Maxim Gonchar wrote:
> And everything that should be done for it is to stop fish calling '-a'
> script when calling completion of 'cmd -'. Just like Sanskrit Fritz have
> written in first message.
>
The problem is actually pretty serious, I just discovered, that
> I can definitely see the benefit of using it that way, however I think
> its
> incorrect, and just exploiting a flaw in the complete command.
If you run 'complete --help' and check examples you will see the usage of
command arguments with su. I think that it was done intentionally and is
no
On Fri, Apr 13, 2012 at 1:54 PM, Maxim Gonchar wrote:
> On Fri, 13 Apr 2012 15:39:20 +0400, Gustaf Johansson
> wrote:
>
> Given the description of 'complete' I would have expected it to behave
>> differently, given:
>>
>>complete (-c|--command|-p|--path) COMMAND [(-s|--short-option)
>> SHOR
On Fri, 13 Apr 2012 15:39:20 +0400, Gustaf Johansson
wrote:
> Given the description of 'complete' I would have expected it to behave
> differently, given:
>
> complete (-c|--command|-p|--path) COMMAND [(-s|--short-option)
> SHORT_OPTION] [(-l|--long-option|-o|--old-option) LONG_OPTION
> [(-
Given the description of 'complete' I would have expected it to behave
differently, given:
complete (-c|--command|-p|--path) COMMAND [(-s|--short-option)
SHORT_OPTION] [(-l|--long-option|-o|--old-option) LONG_OPTION
[(-a||--arguments) OPTION_ARGUMENTS] [(-d|--description) DESCRIPTION]
(which
> So it is intentional then. How can I prevent this behaviour? I toyed with
> __fish_contains_opt, but that is not optimal. I will try to parse
> commandline --current-token but it gets too complicated, it defies the
> simplicity of completions.
Well, the completions mechanism should be updated som
> So it is intentional then. How can I prevent this behaviour? I toyed with
> __fish_contains_opt, but that is not optimal. I will try to parse
> commandline --current-token but it gets too complicated, it defies the
> simplicity of completions.
> I noticed that in nearly *all* occasions the --argu
On Fri, Apr 13, 2012 at 7:57 AM, Maxim Gonchar wrote:
> On Fri, 13 Apr 2012 00:45:27 +0400, SanskritFritz
> wrote:
>
> Consider this foo.fish file:
>>
>> complete --command foo --no-files --short-option a --long-option
>> 'an_example' --description 'example A'
>> complete --command foo --no-fil
But if your --arguments script will return something starting with dash,
fish have to complete it.
Consider this example:
complete -c foo -a '-opt1 -opt2'
Maxim
On Fri, 13 Apr 2012 00:45:27 +0400, SanskritFritz
wrote:
> Consider this foo.fish file:
>
> complete --command foo --no-file
13 matches
Mail list logo