[Monotone-devel] zsh completion annoyance: mtn add

[Steven E. Harris]

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