Re: [PATCH/RFC] completion: complete all possible -no-<options>
- From
Andreas Heiduk <asheiduk@gmail.com>
- Date
- May 14, 2018, 19:58 UTC
- Message-ID
- <bda62b25-a569-9199-5973-2ea7b223ed5d@gmail.com>
- In-Reply-To
- <CACsJy8CwwseqL9M=-ML6hwgHG_GSK6pfeQU+MGWsx6=WCCZtmQ@mail.gmail.com>
Am 14.05.2018 um 19:26 schrieb Duy Nguyen:
Show 49 quoted lines
> On Mon, May 14, 2018 at 7:03 PM, Andreas Heiduk <asheiduk@gmail.com> wrote: >> 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. > > Good to know. > > BTW I looked at the git.fish completion script [1] and see that recent > effort to help automate more in git-completion.bash might help there > too. I notice a lot of options and help text hard coded there, if > someone can explain to me how git.fish uses those, maybe I can change > git to export something suitable for git.fish to use too [2].
I'm no expert, but some additional things required by fish (and I suppose zsh too) but not by bash:
- grouping of long and short options - help text - argument types for options
Help text and long/short option grouping look like this:
> git rebase -<tab>
--force-rebase -f (Force the rebase)
--merge -m (Use merging strategies to rebase)All these infos seem to be available in `struct option` (for C stuff at least). So I guess It would be easiest for Fish & Co if git just exports the complete info in some stable format.
Show 13 quoted lines
> > For example with latest git (in 'master') doing this > > ./git add --git-completion-helper > > gives you the list of all options of "git add". Giving the help text > for each option is definitely possible (I just didn't see any use for > it until I looked at zsh/fish completion scripts) and maybe more in > the future. > > [1] https://github.com/fish-shell/fish-shell/blob/master/share/completions/git.fish > [2] But then if your script has to work with old git versions too then > this is a moot point.
Well, sooner or later those old git versions might not be supported by those shells exactly due to the involved maintenance overhead. So providing some helper is a step in the right direction. Not providing only fossilizes the current state.