[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] zsh completion annoyance: mtn add

From: Steven E. Harris
Subject: [Monotone-devel] zsh completion annoyance: mtn add
Date: Fri, 03 Nov 2006 14:37:31 -0800
User-agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.13 (cygwin32)

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:
          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

¹ 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]