SZEDER Gábor <szeder@xxxxxxxxxx> writes: > After a unique command or option is completed, in most cases it is a > good thing to add a trailing a space, but sometimes it doesn't makes s/makes/make/; > __gitcomp() therefore iterates over all possible completion words it > got as argument, and checks each word whether a trailing space is > necessary or not. This is ok for commands, options, etc., i.e. when > the number of words is relatively small, but can be noticeably slow > for large number of refs. However, while options might or might not > need that trailing space, refs are always handled uniformly and always > get that trailing space (or a trailing '.' for 'git config > branch.<head>.'). > ... > So, add a specialized variant of __gitcomp() that only deals with > possible completion words separated by a newline and uniformly appends > the trailing space to all words using 'compgen -S' (or any other > suffix, if specified), so no iteration over all words is done. s/is done./is needed./; I think I followed your logic (very well written ;-), but feel somewhat dirty, as you are conflating the "These things are separated with newlines" with "These things do not need inspection --- they all need suffix", which has one obvious drawback --- you may find other class of words that always want a SP after each of them but the source that generates such a class of words may not separate the list elements with a newline. Because a ref cannot have $IFS whitespace in its name anyway, I think you can rename __gitcomp_nl to a name that conveys more clearly what it does (i.e. "complete and always append suffix"), drop the IFS fiddling from the function, and get the same optimization, no? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html