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