{"thread":{"id":"48312","subject":"[PATCH/RFC] completion: complete all possible -no-","startedAt":"2018-04-17T18:13:24Z","lastAt":"2018-06-06T09:42:15Z","messageCount":23,"participants":["Nguyễn Thái Ngọc Duy","Junio C Hamano","Duy Nguyen","Eric Sunshine","Stefan Beller","Aaron Schrab","Andreas Heiduk"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"344917","messageId":"20180417181300.23683-1-pclouds@gmail.com","threadId":"48312","inReplyTo":null,"subject":"[PATCH/RFC] completion: complete all possible -no-","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2018-04-17T18:13:00Z","receivedAt":"2018-04-17T18:13:24Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"This is not a complete topic but I'd like to present the problem and\nmy approach to see if it's a good way to go.\n\nWe have started recently to rely on parse-options to help complete\noptions. One of the leftover items is allowing completing --no- form.\nThis patch enables that (some options should not have --no- form, but\nthat's easy not included here).\n\nThe problem with completing --no- form is that the number of\ncompletable options now usually doubles, taking precious screen space\nand also making it hard to find the option you want.\n\nSo the other half of this patch, the part in git-completion.bash, is\nto uncomplete --no- options. When you do \"git checkout --\",\ninstead of displaying all --no- options, this patch simply displays\none item: the --no- prefix. If you do \"git checkout --no-\" then\nall negative options are displayed. This helps reduce completable\noptions quite efficiently.\n\nOf course life is not that simple, we do have --no- options by default\nsometimes (taking priority over the positive form), e.g. \"git clone\n--no-checkout\". Collapsing all --no-options into --no- would be a\nregression.\n\nTo avoid it, the order of options --git-completion-helper returns does\nmatter. The first 4 negative options are not collapsed. Only options\nafter the 4th are. Extra --no- options are always printed at the end,\nafter all the --no- defined in struct option, this kinda works. Not\npretty but works.\n\nAfter all this \"git checkout --\" now looks like this\n\n > ~/w/git $ git co --\n --conflict= --orphan=\n --detach --ours \n --ignore-other-worktrees --patch \n --ignore-skip-worktree-bits --progress \n --merge --quiet \n --no- --recurse-submodules \n --no-detach --theirs \n --no-quiet --track \n --no-track \n\nand all the no options\n\n > ~/w/git $ git co --no-\n --no-conflict --no-patch \n --no-detach --no-progress \n --no-ignore-other-worktrees --no-quiet \n --no-ignore-skip-worktree-bits --no-recurse-submodules \n --no-merge --no-track \n --no-orphan \n\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n contrib/completion/git-completion.bash | 25 +++++++++++++++-\n parse-options.c | 40 +++++++++++++++++++++++---\n 2 files changed, 60 insertions(+), 5 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex a757073945..85b9f24465 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -266,7 +266,7 @@ __gitcomp ()\n \tcase \"$cur_\" in\n \t--*=)\n \t\t;;\n-\t*)\n+\t--no-*)\n \t\tlocal c i=0 IFS=$' \\t\\n'\n \t\tfor c in $1; do\n \t\t\tc=\"$c${4-}\"\n@@ -279,6 +279,29 @@ __gitcomp ()\n \t\t\tfi\n \t\tdone\n \t\t;;\n+\t*)\n+\t\tlocal c i=0 IFS=$' \\t\\n' n=0\n+\t\tfor c in $1; do\n+\t\t\tc=\"$c${4-}\"\n+\t\t\tif [[ $c == \"$cur_\"* ]]; then\n+\t\t\t\tcase $c in\n+\t\t\t\t--*=*|*.) ;;\n+\t\t\t\t--no-*)\n+\t\t\t\t\tn=$(($n+1))\n+\t\t\t\t\tif [ \"$n\" -eq 4 ]; then\n+\t\t\t\t\t\tc=\"--no-${4-} \"\n+\t\t\t\t\telif [ \"$n\" -gt 4 ]; then\n+\t\t\t\t\t\tcontinue\n+\t\t\t\t\telse\n+\t\t\t\t\t\tc=\"$c \"\n+\t\t\t\t\tfi\n+\t\t\t\t\t;;\n+\t\t\t\t*) c=\"$c \" ;;\n+\t\t\t\tesac\n+\t\t\t\tCOMPREPLY[i++]=\"${2-}$c\"\n+\t\t\tfi\n+\t\tdone\n+\t\t;;\n \tesac\n }\n \ndiff --git a/parse-options.c b/parse-options.c\nindex 0f7059a8ab..f6cd7ca8d2 100644\n--- a/parse-options.c\n+++ b/parse-options.c\n@@ -427,13 +427,11 @@ void parse_options_start(struct parse_opt_ctx_t *ctx,\n \tparse_options_check(options);\n }\n \n-/*\n- * TODO: we are not completing the --no-XXX form yet because there are\n- * many options that do not suppress it properly.\n- */\n static int show_gitcomp(struct parse_opt_ctx_t *ctx,\n \t\t\tconst struct option *opts)\n {\n+\tconst struct option *original_opts = opts;\n+\n \tfor (; opts->type != OPTION_END; opts++) {\n \t\tconst char *suffix = \"\";\n \n@@ -465,6 +463,40 @@ static int show_gitcomp(struct parse_opt_ctx_t *ctx,\n \t\t\tsuffix = \"=\";\n \t\tprintf(\" --%s%s\", opts->long_name, suffix);\n \t}\n+\tfor (opts = original_opts; opts->type != OPTION_END; opts++) {\n+\t\tint has_unset_form = 0;\n+\n+\t\tif (!opts->long_name)\n+\t\t\tcontinue;\n+\t\tif (opts->flags & (PARSE_OPT_HIDDEN | PARSE_OPT_NOCOMPLETE))\n+\t\t\tcontinue;\n+\t\tif (opts->flags & PARSE_OPT_NONEG)\n+\t\t\tcontinue;\n+\n+\t\tswitch (opts->type) {\n+\t\tcase OPTION_STRING:\n+\t\tcase OPTION_FILENAME:\n+\t\tcase OPTION_INTEGER:\n+\t\tcase OPTION_MAGNITUDE:\n+\t\tcase OPTION_CALLBACK:\n+\t\tcase OPTION_BIT:\n+\t\tcase OPTION_NEGBIT:\n+\t\tcase OPTION_COUNTUP:\n+\t\tcase OPTION_SET_INT:\n+\t\t\thas_unset_form = 1;\n+\t\t\tbreak;\n+\t\tdefault:\n+\t\t\tbreak;\n+\t\t}\n+\t\tif (has_unset_form) {\n+\t\t\tconst char *name;\n+\n+\t\t\tif (skip_prefix(opts->long_name, \"no-\", &name))\n+\t\t\t\tprintf(\" --%s\", name);\n+\t\t\telse\n+\t\t\t\tprintf(\" --no-%s\", opts->long_name);\n+\t\t}\n+\t}\n \tfputc('\\n', stdout);\n \texit(0);\n }\n-- \n2.17.0.367.g5dd2e386c3\n\n"},{"id":"344966","messageId":"xmqq604pji2f.fsf@gitster-ct.c.googlers.com","threadId":"48312","inReplyTo":"20180417181300.23683-1-pclouds@gmail.com","subject":"Re: [PATCH/RFC] completion: complete all possible -no-","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-04-18T03:43:04Z","receivedAt":"2018-04-18T03:43:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyễn Thái Ngọc Duy writes:\n\n> So the other half of this patch, the part in git-completion.bash, is\n> to uncomplete --no- options. When you do \"git checkout --\",\n> instead of displaying all --no- options, this patch simply displays\n> one item: the --no- prefix. If you do \"git checkout --no-\" then\n> all negative options are displayed. This helps reduce completable\n> options quite efficiently.\n\nClever.\n\n> Of course life is not that simple, we do have --no- options by default\n> sometimes (taking priority over the positive form), e.g. \"git clone\n> --no-checkout\". Collapsing all --no-options into --no- would be a\n> regression.\n>\n> To avoid it, the order of options --git-completion-helper returns does\n> matter. The first 4 negative options are not collapsed. Only options\n> after the 4th are. Extra --no- options are always printed at the end,\n> after all the --no- defined in struct option, this kinda works. Not\n> pretty but works.\n\nSo, the earlier mention of \"clone --no-checkout\" sounded about not\nlosing this historical practice, but (desirabilty of magic number 4\naside) this \"show first handful of --no-foo\" feature is not about\nhistorical practice but is forward looking, in the sense that you do\nnot mark \"important\" negated options in the source, which would be a\nway to handle the histrical \"clone --no-checkout\", but let the\nmachinery mechanically choose among --no-foo (with the stupid choice\ncriterion \"first four are shown\"). That allows other commands to\nhave many --no-foo form without overwhelming the choices, but I am\nnot sure if it is much better than a possible alternative of only\nshowing --no-foo for more \"important\" foo's when show_gitcomp() is\nasked to list all of things. It would certainly be a more involved\nsolution, that might require an update to the way how the choices\nare precomputed (you'd end up having to keep a separate \"use this\nlist when completing '--no-'\" in addition to the normal list).\n\nIn any case, count this as a vote to support an update in this\ndirection. A quite promising work ;-)\n\nThanks.\n"},{"id":"344989","messageId":"CACsJy8CU255jmXFRXVEQUBCvUiDhRHLyTOhMorzyCDYZ4aF9xg@mail.gmail.com","threadId":"48312","inReplyTo":"xmqq604pji2f.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH/RFC] completion: complete all possible -no-","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-04-18T15:08:50Z","receivedAt":"2018-04-18T15:09:26Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Apr 18, 2018 at 5:43 AM, Junio C Hamano wrote:\n> So, the earlier mention of \"clone --no-checkout\" sounded about not\n> losing this historical practice, but (desirabilty of magic number 4\n> aside) this \"show first handful of --no-foo\" feature is not about\n> historical practice but is forward looking, in the sense that you do\n> not mark \"important\" negated options in the source, which would be a\n> way to handle the histrical \"clone --no-checkout\", but let the\n> machinery mechanically choose among --no-foo (with the stupid choice\n> criterion \"first four are shown\").\n\nWell you kinda mark important in the source too. --no-checkout for\nexampled is declared as OPT_BOOL(0, \"no-checkout\"... and parse-options\ncode has to add the double-negative form --checkout back [1].\n\nThe \"first four\" is chosen after carefully examining all commands and\nobserving that none of them have more than 4 \"important\" --no-. But\nyes it is questionable and I should be able to do better to separate\nthe favorable --no- from the other extra and most-of-the-time-useless\n--no- options.\n\n> That allows other commands to\n> have many --no-foo form without overwhelming the choices, but I am\n> not sure if it is much better than a possible alternative of only\n> showing --no-foo for more \"important\" foo's when show_gitcomp() is\n> asked to list all of things. It would certainly be a more involved\n> solution, that might require an update to the way how the choices\n> are precomputed (you'd end up having to keep a separate \"use this\n> list when completing '--no-'\" in addition to the normal list).\n\nI did think about this alternative and was still undecided. Suppose\nthat you have less than 4 \"important\" --no- options, showing some\nextra ones to me does not really hurt anything and if we could show\nmore options (within the same screen space) we should. But on the\nother hand maintaining this magic number could be a maintenance\nnightmare... Yeah I think I'm shifting towards no magic number now.\n\n[1] These double negative options will _always_ show up, there is no\neasy way to hide them because they don't start with --no-. But we\ndon't have a lot of options starting with \"no-\" so it's probably fine.\n-- \nDuy\n"},{"id":"345445","messageId":"CAPig+cRkUrdtbyGEsY=DQCDoEWTrC-9n4=vKXHEap2gokB2uQg@mail.gmail.com","threadId":"48312","inReplyTo":"20180417181300.23683-1-pclouds@gmail.com","subject":"Re: [PATCH/RFC] completion: complete all possible -no-","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2018-04-23T05:36:17Z","receivedAt":"2018-04-23T05:36:24Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Tue, Apr 17, 2018 at 2:13 PM, Nguyễn Thái Ngọc Duy wrote:\n> The problem with completing --no- form is that the number of\n> completable options now usually doubles, taking precious screen space\n> and also making it hard to find the option you want.\n>\n> So the other half of this patch, the part in git-completion.bash, is\n> to uncomplete --no- options. When you do \"git checkout --\",\n> instead of displaying all --no- options, this patch simply displays\n> one item: the --no- prefix. If you do \"git checkout --no-\" then\n> all negative options are displayed. This helps reduce completable\n> options quite efficiently.\n>\n> After all this \"git checkout --\" now looks like this\n>\n> > ~/w/git $ git co --\n> --conflict= --orphan=\n> --detach --ours\n> --ignore-other-worktrees --patch\n> --ignore-skip-worktree-bits --progress\n> --merge --quiet\n> --no- --recurse-submodules\n> --no-detach --theirs\n> --no-quiet --track\n> --no-track\n\nI haven't looked at the implementation, so this may be an entirely\nstupid suggestion, but would it be possible to instead render the\ncompletions as?\n\n % git checkout --\n --[no-]conflict= --[no-]patch\n --[no-]detach --[no-]progress\n --[no-]ignore-other-worktrees --[no-]quiet\n --[no-]ignore-skip-worktree-bits --[no-]recurse-submodules\n --[no-]merge --theirs\n --[no-]orphan= --[no-]track\n --ours\n\nThis would address the problem of the --no-* options taking double the\nscreen space.\n\nIt's also more intuitive than that lone and somewhat weird-looking\n\"--no-\" suggestion.\n"},{"id":"346990","messageId":"CACsJy8BGs7EOYFKayL-bgvEbKOJiROF52o3SneLyG9Nm6nUngA@mail.gmail.com","threadId":"48312","inReplyTo":"CAPig+cRkUrdtbyGEsY=DQCDoEWTrC-9n4=vKXHEap2gokB2uQg@mail.gmail.com","subject":"Re: [PATCH/RFC] completion: complete all possible -no-","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-05-08T15:24:02Z","receivedAt":"2018-05-08T15:24:38Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Apr 23, 2018 at 7:36 AM, Eric Sunshine wrote:\n> I haven't looked at the implementation, so this may be an entirely\n> stupid suggestion, but would it be possible to instead render the\n> completions as?\n>\n> % git checkout --\n> --[no-]conflict= --[no-]patch\n> --[no-]detach --[no-]progress\n> --[no-]ignore-other-worktrees --[no-]quiet\n> --[no-]ignore-skip-worktree-bits --[no-]recurse-submodules\n> --[no-]merge --theirs\n> --[no-]orphan= --[no-]track\n> --ours\n>\n> This would address the problem of the --no-* options taking double the\n> screen space.\n\nIt took me so long to reply partly because I remember seeing some guy\ndoing clever trick with tab completion that also shows a short help\ntext in addition to the complete words. I could not find that again\nand from my reading (also internet searching) it's probably not\npossible to do this without trickery.\n\n> It's also more intuitive than that lone and somewhat weird-looking\n> \"--no-\" suggestion.\n\nIt's not that weird if you think about file path completion, where you\ncomplete one path component at a time not full path, bash just does\nnot show you full paths to everything.\n\nI'm arguing about this because I want to see your reaction, because\nI'm thinking of doing the very same thing for config completion. Right\nnow \"git config \" gives you two pages of all available config\nvariables. I'm thinking that we \"git config \" just shows the\ngroups, e.g.\n\n> ~/w/git $ git config\nadd. interactive.\nadvice. log.\nalias. mailmap.\nam. man.\n\nOnly when you do \"git config log.\" that it shows you log.*\n-- \nDuy\n"},{"id":"346993","messageId":"CAGZ79kb1VEkB4aw9ukx1LsOUX7=HzFcC=2=LwU4ipFEH60ALag@mail.gmail.com","threadId":"48312","inReplyTo":"CACsJy8BGs7EOYFKayL-bgvEbKOJiROF52o3SneLyG9Nm6nUngA@mail.gmail.com","subject":"Re: [PATCH/RFC] completion: complete all possible -no-","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-05-08T16:39:12Z","receivedAt":"2018-05-08T16:39:16Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, May 8, 2018 at 8:24 AM, Duy Nguyen wrote:\n\n> I'm arguing about this because I want to see your reaction, because\n> I'm thinking of doing the very same thing for config completion. Right\n> now \"git config \" gives you two pages of all available config\n> variables. I'm thinking that we \"git config \" just shows the\n> groups, e.g.\n>\n>> ~/w/git $ git config\n> add. interactive.\n> advice. log.\n> alias. mailmap.\n> am. man.\n>\n> Only when you do \"git config log.\" that it shows you log.*\n\nHow cool is that? I'd love it.\n"},{"id":"347049","messageId":"20180509032050.GA23510@pug.qqx.org","threadId":"48312","inReplyTo":"CACsJy8BGs7EOYFKayL-bgvEbKOJiROF52o3SneLyG9Nm6nUngA@mail.gmail.com","subject":"Re: [PATCH/RFC] completion: complete all possible -no-","fromName":"Aaron Schrab","fromEmail":"aaron@schrab.com","sentAt":"2018-05-09T03:20:50Z","receivedAt":"2018-05-09T03:28:19Z","isPatch":true,"sender":{"key":"aaron@schrab.com","avatar":"https://avatars.githubusercontent.com/u/39620?v=4"},"body":"At 17:24 +0200 08 May 2018, Duy Nguyen wrote:\n>It took me so long to reply partly because I remember seeing some guy\n>doing clever trick with tab completion that also shows a short help\n>text in addition to the complete words. I could not find that again\n>and from my reading (also internet searching) it's probably not\n>possible to do this without trickery.\n\nWas that perhaps using zsh rather than bash? Below is some of the \ndisplay from its git completion (this is likely affected somewhat by my \nconfiguration). The group descriptions (lines that begin with \n\"Completing\") appear in a different color, and are not available for \nselection.\n\n1113$ git c\nCompleting alias\nci -- alias for 'commit -v'\ncia -- alias for 'commit -v -a'\nco -- alias for 'checkout'\nconf -- alias for 'config'\nCompleting main porcelain command\ncheckout -- checkout branch or paths to working tree\ncherry-pick -- apply changes introduced by some existing commits\ncitool -- graphical alternative to git commit\nclean -- remove untracked files from working tree\nclone -- clone repository into new directory\ncommit -- record changes to repository\nCompleting ancillary manipulator command\nconfig -- get and set repository or global options\nCompleting ancillary interrogator command\ncherry -- find commits not merged upstream\ncount-objects -- count unpacked objects and display their disk consumption\nCompleting plumbing manipulator command\ncheckout-index -- copy files from index to working directory\ncommit-tree -- create new commit object\nCompleting plumbing interrogator command\ncat-file -- provide content or type information for repository objects\n\n1114$ git commit -\nCompleting option\n--all -a -- stage all modified and deleted paths\n--allow-empty -- allow recording an empty commit\n--allow-empty-message -- allow recording a commit with an empty message\n--amend -- amend the tip of the current branch\n--author -- override the author name used in the commit\n"},{"id":"347567","messageId":"CAPig+cRUD7FnJqSZ=hkz0GAgOROiY+gvHKRjKVfkKtqDZyt5mA@mail.gmail.com","threadId":"48312","inReplyTo":"CACsJy8BGs7EOYFKayL-bgvEbKOJiROF52o3SneLyG9Nm6nUngA@mail.gmail.com","subject":"Re: [PATCH/RFC] completion: complete all possible -no-","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2018-05-14T03:33:07Z","receivedAt":"2018-05-14T03:33:11Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Tue, May 8, 2018 at 11:24 AM, Duy Nguyen wrote:\n> On Mon, Apr 23, 2018 at 7:36 AM, Eric Sunshine wrote:\n>> I haven't looked at the implementation, so this may be an entirely\n>> stupid suggestion, but would it be possible to instead render the\n>> completions as?\n>>\n>> % git checkout --\n>> --[no-]conflict= --[no-]patch\n>> --[no-]detach --[no-]progress\n>>\n>> This would address the problem of the --no-* options taking double the\n>> screen space.\n>\n> It took me so long to reply partly because I remember seeing some guy\n> doing clever trick with tab completion that also shows a short help\n> text in addition to the complete words. I could not find that again\n> and from my reading (also internet searching) it's probably not\n> possible to do this without trickery.\n\nOkay.\n\n>> It's also more intuitive than that lone and somewhat weird-looking\n>> \"--no-\" suggestion.\n>\n> It's not that weird if you think about file path completion, where you\n> complete one path component at a time not full path, bash just does\n> not show you full paths to everything.\n\nThe \"path completion\" analogy and the dotted configuration variable\nanalogy (below) don't really help me find \"--no-\" less weird. We're\nused to \"/\" as a separator in paths, and \".\" a separator in\nconfiguration variables, so they are easier to digest than \"-\" somehow\nbeing a separator for --no-