Summary
Bare currently completes executables, files/directories, and switches parsed from --help output. There is no way for users or packages to define custom completion for a specific command's arguments — analogous to bash's complete -F _cmd cmd mechanism.
Use case
Consider ebuild, which takes two kinds of positional arguments in sequence:
- a
*.ebuild file
- one or more phase names (
fetch, unpack, compile, install, merge, …)
A bash completion for this looks like:
_ebuild() {
local cmds=(help setup clean fetch unpack compile test install merge ...)
# after a filename: complete phases; before: complete *.ebuild files
if [[ ${seenf} ]]; then
COMPREPLY=( $(compgen -W "${cmds[*]}" -- "${cur}") )
else
_filedir ebuild
fi
}
complete -F _ebuild ebuildThere is no equivalent in bare. The plugin system only handles :colon-commands, not argument completion for external programs.
Proposal
Add a completion spec directory, e.g. ~/.bare/completions/, where each file is named after a command and describes how to complete its arguments. A minimal format could be:
# ~/.bare/completions/ebuild
# positional arg 1: files matching *.ebuild
arg1: glob:*.ebuild
# positional arg 2+: fixed word list
arg2+: words:help setup clean fetch unpack compile test install merge unmerge preinst postinst prerm postrm configure prepare
# flags: already handled via --help parsing, but can be listed explicitly
flags: --debug --force --ignore-default-opts --skip-manifest --help
Or, alternatively, a script-based approach where bare execs ~/.bare/completions/<cmd> with the current token and word index on stdin/argv, and reads candidate strings from stdout — similar to how fish shell's completions work.
Why this matters
Bare's --help-based switch completion is a great zero-config feature. Extending the same spirit to argument position would make bare viable as a daily shell for users who rely on rich completions (package managers, build tools, deployment CLIs) without requiring those tools to be aware of bare.
Summary
Bare currently completes executables, files/directories, and switches parsed from
--helpoutput. There is no way for users or packages to define custom completion for a specific command's arguments — analogous to bash'scomplete -F _cmd cmdmechanism.Use case
Consider
ebuild, which takes two kinds of positional arguments in sequence:*.ebuildfilefetch,unpack,compile,install,merge, …)A bash completion for this looks like:
There is no equivalent in bare. The plugin system only handles
:colon-commands, not argument completion for external programs.Proposal
Add a completion spec directory, e.g.
~/.bare/completions/, where each file is named after a command and describes how to complete its arguments. A minimal format could be:Or, alternatively, a script-based approach where bare execs
~/.bare/completions/<cmd>with the current token and word index on stdin/argv, and reads candidate strings from stdout — similar to how fish shell's completions work.Why this matters
Bare's
--help-based switch completion is a great zero-config feature. Extending the same spirit to argument position would make bare viable as a daily shell for users who rely on rich completions (package managers, build tools, deployment CLIs) without requiring those tools to be aware of bare.