On 2018-04-25 16:40, SZEDER Gábor wrote:
In my previous emails I overlooked the _completion_loader() helper
function.
It seems that this function does almost exactly what we want. It was
introduced along with dynamic completion loading back in 20c05b43, so
it's available for us even in older LTS/Enterprise releases. Since
cad3abfc it's a wrapper around __load_completion() and thus benefits
from all the improvements, notably searching for completion scripts in
a user-specified directory ($BASH_COMPLETION_USER_DIR) or in the
user's home directory ($XDG_DATA_HOME or ~/.local/...) as well. It
loads the matching completion script, but does not call the completion
function unconditionally.
Sounds good so far.
The "almost" refers to he case when _completion_loader() can't find a
completion script with a matching name to load, and then registers the
_minimal() completion function for the given command to do basic path
completion as fallback. I don't think this matters in practice,
because in this case the given command is a git command in its dashed
form, e.g. 'git-diff-index', and those have been deprecated for a long
time.
I sense a problem here. If I have a directory with a file xyzfoobar in
it, and I type `git xyz`, with no defined subcommand that starts with
these letters, then minimal bashcomp would give me `git xyzfoobar`,
which can of course not execute. This can be unintuitive for users, as
in: "If it can't be executed correctly, then why does it even suggest
such a completion?"
I think all you need to do is run a
s/__load_completion/_completion_loader/ on your patch and update the
commit message with relevant bits from the above discussion.
I can do that, no problem. But prior to that I want to be sure that you
are okay with the above mentioned drawback. Will the behavior be
acceptable in this case? Or should we try to somehow "undo" the minimal
completion afterwards?