Options like --sub-file are aliases for list actions like
--sub-files-append, which --list-options shows without a type, so
nothing was completed after them. Follow aliases to their target, and
complete typeless list actions like the list option they act on.
This makes --sub-file=, --audio-file=, --glsl-shader=, --script= etc.
complete files, --sub-files-append= etc. complete files when typed
directly, and other aliases like --fs= and --audio= complete the values
of their target.
Fixes#7955.
The special-options regex decided which options are completed without
a trailing '=', but it only covered Print options and "not in config
files" flags. As a result, two groups of no-argument options still got
'=' appended:
(1) *-clr / *-help sub-options (e.g. --af-clr, --vo-help) which are
mpv list-type sub-options taking no argument.
(2) --help/--h which is String-typed in --list-options but actually
accepts a substring filter to narrow down the option listing.
Extend the regex to cover (1). For (2), keep '=' appended (it does take
an argument) and route completion through a new Help branch that mirrors
the zsh help-options state: complete bare option names (no "--"
prefix), excluding no-* negations and list-type sub-options
(-add/-append/-clr/-pre/-set/-remove/-toggle). Bare names are needed
because --help=<substring> matches within the option name body.
Hashbangs are meant for scripts that are executed, but a bash completion
script is meant to be sourced and therefor shouldn't have a hashbang.
Remarked by Debian's ``lintian`` tool with the
``bash-completion-with-hashbang`` tag.
We were over-enthusiastic when introducing --no-config into the
autocompletions. When autocompleting profiles, you actually need the
config, because that's where the profiles come from.
zsh is untested - I don't use it.
Reading the config when we're just interested in the option list
(not sure why mpv does that anyway) only has the potential to mess
this process up when it prints errors or the user has funny options
like msg-level or log-file set, so avoid doing so.
If bash_completion wasn't installed, _filedir wouldn't be defined which
led to all filename-based completions to error out. Specifically
autocompletion would fail when a filename was expected and when
bash_completion wasn't installed. Now we fall back to `compgen -f` if
_filedir fails. According to _filedir's comments, compgen doesn't
handle files with spaces well, but it is still better to complete most
files than none.
The bash completion seems to be working decently at this point, so I
feel comfortable caching the options output to improve the performance
of the completion.
Right now we are generating the fully option list before doing
anything else. That makes filename completion significantly slower
than it was before, for no gain. It's easy to only generate the
option list when it's actually needed.
I also know I could additionally cache the option list across
invocations, but I'm not doing that yet to make testing easier.
While we've had a zsh completion script for a while, we haven't had
one for bash. This one is reasonably comprehensive, although there are
improvements one could imagine for certain options.
shbernal