{"thread":{"id":"43684","subject":"Calling all bash completion experts..","startedAt":"2006-11-23T17:45:29Z","lastAt":"2006-11-26T04:03:58Z","messageCount":4,"participants":["Linus Torvalds","Shawn Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"296646","messageId":"Pine.LNX.4.64.0611230935520.27596@woody.osdl.org","threadId":"43684","inReplyTo":null,"subject":"Calling all bash completion experts..","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-23T17:45:29Z","receivedAt":"2006-11-23T17:45:29Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nSo, I'm a happy but clueless user of the bash completion, and one thing \ndrives me wild: when it has found an exclusive completion, it doesn't add \nthe final space at the end, but just beeps at you when you again.\n\nSo I do \"git repa\" and get \"git repack\", which is fine, but I really \n_wanted_ to get \"git repack \" (with the space at the end), since I've now \ngot a unique command, and that's the normal completion behaviour (ie I \nwant it to act the same way that \"git-repa\" would have acted).\n\nThe same is true of filename arguments, btw:\n\n\tgit commit contcom\n\ngives me\n\n\tgit commit contrib/completion/git-completion.bash\n\nbut again, it doesn't seem to do the right thing about the fact that it \nwas the unique choice, so it didn't add the final space, and when you \npress more to get what the other choices are, it doesn't show you \nany other choices (because there are none).\n\nNow, without knowing the completion syntax, I assume it's the \"-o nospace\" \nthings in the completion file. So I'm wondering _why_ that \"nospace\" is \nthere, and whether this could be fixed?\n\n"},{"id":"298089","messageId":"20061125071351.GE4528@spearce.org","threadId":"43684","inReplyTo":"Pine.LNX.4.64.0611230935520.27596@woody.osdl.org","subject":"Re: Calling all bash completion experts..","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-25T07:13:51Z","receivedAt":"2006-11-25T07:13:51Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> So I do \"git repa\" and get \"git repack\", which is fine, but I really \n> _wanted_ to get \"git repack \" (with the space at the end), since I've now \n> got a unique command, and that's the normal completion behaviour (ie I \n> want it to act the same way that \"git-repa\" would have acted).\n[snip]\n> Now, without knowing the completion syntax, I assume it's the \"-o nospace\" \n> things in the completion file. So I'm wondering _why_ that \"nospace\" is \n> there, and whether this could be fixed?\n\nYes, its the \"-o nospace\".\n\nI added the nospace option because of the completion for fetch/push,\ncat-file, diff-tree and ls-tree.\n\nThe problem is the file completion for e.g. cat-file. We don't\nwant a space added after we complete a directory name, so you can\ncomplete further, e.g.:\n\n git cat-file -p maconcompgit-com\n\ngives us:\n\n git cat-file -p master:contrib/completion/git-completion.sh\n\nbut if I omitted the \"-o nospace\" then we would instead need:\n\n git cat-file maconcompgit-com\n\nas each successive would add a trailing space that you would need\nto remove before you can complete again.\n\nSo as a user I decided that adding the space myself was less\nannoying then needing to delete the space during completion down\nthrough a tree. But perhaps that was wrong.\n\nI did try to inject the space myself in the completion code when\nI knew something was unique, but bash didn't like that (it tossed\nthe space).\n\nTo be honest, I'm not really sure how to fix it.\n\nOne option would be to perform a `ls-tree -r` through whatever part\nof the path we have now and offer up EVERYTHING in the tree as a\npossible completion, but that is insane as it will take a little\nwhile to generate and on a large tree (e.g. the Linux kernel) you\nwill get a large number of proposed completions back which aren't\nreally relevant.\n\n-- \n"},{"id":"296970","messageId":"Pine.LNX.4.64.0611251106250.6991@woody.osdl.org","threadId":"43684","inReplyTo":"20061125071351.GE4528@spearce.org","subject":"Re: Calling all bash completion experts..","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-25T19:08:28Z","receivedAt":"2006-11-25T19:08:28Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 25 Nov 2006, Shawn Pearce wrote:\n> \n> I added the nospace option because of the completion for fetch/push,\n> cat-file, diff-tree and ls-tree.\n> \n> The problem is the file completion for e.g. cat-file. We don't\n> want a space added after we complete a directory name, so you can\n> complete further, e.g.:\n> \n> git cat-file -p maconcompgit-com\n\nBut that's how directory completion _always_ works. Completion doesn't add \nspaces to directories anyway, it adds a \"/\".\n\nThe branch-name thing is well-taken: you don't want to add a space after a \nbranch-name, although neither do you want to add a \":\" by default.\n\nSo \"nospace\" after a branch (or tag) name sounds sane, but nowhere else \nthat I can see.\n\n"},{"id":"298551","messageId":"20061126040358.GA29855@spearce.org","threadId":"43684","inReplyTo":"Pine.LNX.4.64.0611251106250.6991@woody.osdl.org","subject":"Re: Calling all bash completion experts..","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-26T04:03:58Z","receivedAt":"2006-11-26T04:03:58Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> \n> On Sat, 25 Nov 2006, Shawn Pearce wrote:\n> > \n> > I added the nospace option because of the completion for fetch/push,\n> > cat-file, diff-tree and ls-tree.\n> > \n> > The problem is the file completion for e.g. cat-file. We don't\n> > want a space added after we complete a directory name, so you can\n> > complete further, e.g.:\n> > \n> > git cat-file -p maconcompgit-com\n> \n> But that's how directory completion _always_ works. Completion doesn't add \n> spaces to directories anyway, it adds a \"/\".\n> \n> The branch-name thing is well-taken: you don't want to add a space after a \n> branch-name, although neither do you want to add a \":\" by default.\n> \n> So \"nospace\" after a branch (or tag) name sounds sane, but nowhere else \n> that I can see.\n\nAll in all what you are asking is reasonable. Users really should\nexpect the Git completion to work just like any other completion\nbuilt-in to bash. I've just run into some difficulty making that\nbe the case with all of the git commands. :)\n\nI'm trying to push really hard on git-gui right now, to get it to\nthe point that people who are absolutely terrified of the command\nline can still do basic operations (commit, fetch, trivial merge,\npush). 'cause I really need to get a some of those users onto\na git repository (like everyone else) rather than an unbacked-up\nnetwork share which has no revision history.\n\nI'll come back to the bash completion soon. Jakub Narebski and\nanother person have both asked that I do some more work for other\ncommands. I was hoping that other person might do some of the\nmodifications himself and contribute them back, but it looks like\nhe's just as busy as I am and hasn't found the time.\n\n-- \n"}]}