Re: [PATCH/RFC] completion: complete all possible -no-<options>

[Andreas Heiduk <asheiduk@gmail.com>]

Am 08.05.2018 um 17:24 schrieb Duy Nguyen:
> On Mon, Apr 23, 2018 at 7:36 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> I haven't looked at the implementation, so this may be an entirely
>> stupid suggestion, but would it be possible to instead render the
>> completions as?
>>
>>     % git checkout --<tab>
>>     --[no-]conflict=                   --[no-]patch
>>     --[no-]detach                      --[no-]progress
>>     --[no-]ignore-other-worktrees      --[no-]quiet
>>     --[no-]ignore-skip-worktree-bits   --[no-]recurse-submodules
>>     --[no-]merge                       --theirs
>>     --[no-]orphan=                     --[no-]track
>>     --ours
>>
>> This would address the problem of the --no-* options taking double the
>> screen space.
> 
> It took me so long to reply partly because I remember seeing some guy
> doing clever trick with tab completion that also shows a short help
> text in addition to the complete words. I could not find that again
> and from my reading (also internet searching) it's probably not
> possible to do this without trickery.

The fish-shell does something like that.

    > git status --<tab here>
    --branch  (Show the branch and tracking info even in short-format)
    --help                       (Display the manual of a git command)
    --ignore-submodules                 (Ignore changes to submodules)
    --porcelain    (Give the output in a stable, easy-to-parse format)
    --short                      (Give the output in the short-format)
    --untracked-files              (The untracked files handling mode)

Another tab will put a selection-cursor on the displayed list - you can
navigate that list with Cursor-Up/Cursor-Down, select an entry and that
entry will be inserted into the commandline. That selection process
would be useless if the options are presented as "--[no-]x" because THAT
cannot be inserted into the commandline without manual editing. And
that's the point of the fast option selection process.

> 
>> It's also more intuitive than that lone and somewhat weird-looking
>> "--no-" suggestion.
> 
> It's not that weird if you think about file path completion, where you
> complete one path component at a time not full path, bash just does
> not show you full paths to everything.
> 
> I'm arguing about this because I want to see your reaction, because
> I'm thinking of doing the very same thing for config completion. Right
> now "git config <tab>" gives you two pages of all available config
> variables. I'm thinking that we "git config <tab>" just shows the
> groups, e.g.
> 
>> ~/w/git $ git config
> add.              interactive.
> advice.           log.
> alias.            mailmap.
> am.               man.
> 
> Only when you do "git config log.<tab>" that it shows you log.*
>