Re: [PATCH v2 1/1] completion: load completion file for external subcommand

> On Sun, Apr 29, 2018 at 1:15 PM, Florian Gamböck <mail@floga.de> 
> wrote:
>> 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'm not sure I understand the problem.  After 'git xyz<TAB>' (note 
> there is no space between 'xyz' and <TAB>) we try to complete the name 
> of a git command, not options of a git command.  This means:
>
>  - At this point we don't look for a _git_xyz() function, so we'll 
>  return from __git_main() before even reaching the piece of code your 
>  patch modifies.
>
>  - There are (presumably) no commands starting with 'xyz', so we don't 
>  list any commands.  Bash will then fall back to its own filename 
>  completion, and that's where that 'xyzfoobar' will come from.  It has 
>  been behaving like this basically since forever.
>
> And after 'git xyz <TAB>' (this time with space) we already complete 
> the next word, not 'xyz'.

>>> 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?
>
> As explained above, I don't think there is any drawback here.  Or at 
> least not any new drawback that your patch is introducing.  Or I'm 
> completely missing your point; certainly a possibility, it's early 
> Sunday afternoon, after all :)