Using the most recent monotone zsh completion file from the net.venge.monotone branch against zsh version 4.3.2 (on Cygwin) and monotone version 0.30, I noticed the following annoyance. When one tries to use tab completion to complete a path to a file as an argument to "mtn add", the completion function rejects any leading paths that are already known. An example would make this clear:
Source Tree: . src foo bar baz.h quux.h [unknown] obj [unknown] obj1.o [unknown] Say that src/foo/bar/baz.h is a known file, while both src/foo/bar/quux.h and obj/obj1.o are unknown. In fact, the entire obj directory is unknown. Now one wishes to add quux.h to the repository: mtn add sr[tab] No completions are available. mtn add src/foo/bar/q[tab] Now quux.h gets completed. Though I don't understand much of the zsh completion definition syntax, it looks like the "add" completer is using "mtn ls unknown" to build its candidate set.¹ Now, src/foo/bar/quux.h is in that candidate set, but my *guess* is that since "src" is a known directory, as is "src/foo" and "src/foo/bar", these prefixes get rejected, and no useful completing gets done on the way down to quux.h. This is particularly onerous for projects with deep directory trees. Is it possible to adjust the rejection mechanism to make such completion possible? Perhaps it's more useful to tolerate potential completion of a known file than to reject completion of an unknown file. Footnotes: ¹ Per this definition: (( $+functions[_mtn_add] )) || _mtn_add() { _arguments -s : \ '--unknown[add unknown files from workspace]'\ '*:file to add:_mtn_files_unknown' } -- Steven E. Harris _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel