Am 08.05.2018 um 17:24 schrieb Duy Nguyen:
> On Mon, Apr 23, 2018 at 7:36 AM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> 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.*
>
