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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2018-04-29 15:08, SZEDER Gábor wrote:
On Sun, Apr 29, 2018 at 1:15 PM, Florian Gamböck <mail@xxxxxxxx> 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'.

You are absolutely right! I don't know what my brain was making up here, I am sorry. The minimal completion will come up regardless if no valid completion can be found. I think I mixed up the meaning of $cword in __git_main. It is correct, if I want to complete `git xyz<TAB>`, then my patch is never reached.

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 :)

Okay, then I'll prepare the next round. Thank you very much for your helpful feedback!



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux