_arguments -C … && ret=0 or _arguments -C … && return 0

_arguments -C … && ret=0 or _arguments -C … && return 0

[Nikolai Weibull]

Hi!

What’s the preferred way of dealing with _arguments calls that may use actions?

Etc/completion-style-guide suggests using _arguments -C … && return 0,
but many completion definitions use _arguments -C … && ret=0.

For example, Completion/Unix/Command/_bzip2 uses the_arguments -C … &&
ret=0 style.  This leads to files matching -* being included as
completions.  Is this desired behavior, or is it simply a bug?

Current behavior:

% touch ./--hello
% bzip2 --h^I
[option]
--help               display help message
[file to compress]
--hello

For most commands, completing a file name that looks like an option
will result in an error, so my gut feeling is that we should return
instead of looking for the additional possible completions.

Re: _arguments -C ... && ret=0 or _arguments -C ... && r eturn 0

[Bart Schaefer]

On Jul 21,  3:57pm, Nikolai Weibull wrote:
}
} Etc/completion-style-guide suggests using _arguments -C ... && return 0,
} but many completion definitions use _arguments -C ... && ret=0.
} 
} For example, Completion/Unix/Command/_bzip2 uses the_arguments -C ... &&
} ret=0 style.  This leads to files matching -* being included as
} completions.  Is this desired behavior, or is it simply a bug?

Assuming that ultimately there's eventually a "return ret" then as far
as the caller of the completion function is concerned there's not going
to be any difference.

So whether it's a bug is going to be specific to each function, based
on what else that function does after assigning ret=0.  Handling of
->state forms comes to mind.

} For most commands, completing a file name that looks like an option
} will result in an error, so my gut feeling is that we should return
} instead of looking for the additional possible completions.

What if there's a matcher spec that might complete "-b" into "foo-bar"?