Writing multi-part command completion functions

Writing multi-part command completion functions

[Felix Rosencrantz]

Is there a recommended way to deal with multi-part commands.  For
example, many of  the source control systems cvs, rcs, sccs, and prcs
all have a main command, with the first argument typically being a
sub-command.  Many times the sub-command can be abbreviated.

There are already some completion functions that handle commands like
this (e.g. _cvs).  Is there a preferred way to do this? Is there one
that provides a better example of how to structure such a completion
function(s)?  Would it make sense to add support to make it easier to write
such a function?

Thanks
-FR.


__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/

Re: Writing multi-part command completion functions

[Bart Schaefer]

On Oct 26,  8:12am, Felix Rosencrantz wrote:
} Subject: Writing multi-part command completion functions
}
} Is there a recommended way to deal with multi-part commands.
} 
} There are already some completion functions that handle commands like
} this (e.g. _cvs).  Is there a preferred way to do this?

The method used in _cvs is pretty close to the best possible, I think.
Write a completer for each subcommand as if it were a shell command on
its own, then use the completer for the "outer" command to select among
those.  (In _cvs, this is handled by the _cvs_commands function.)

} Would it make sense to add support to make it easier to write such a
} function?

There is already support for this in _arguments:

    *:MESSAGE:ACTION
    *::MESSAGE:ACTION
    *:::MESSAGE:ACTION
          This describes how arguments (usually non-option arguments,
          those not beginning with - or +) are to be completed when no
          description with one of the first two forms was given. This
          also means that any number of arguments can be completed.

          With two colons before the MESSAGE, the words special array
          and the CURRENT special parameter are modified to refer only
          to the normal arguments when the ACTION is executed or
          evaluated.  With three colons before the MESSAGE they are
          modified to refer only to the normal arguments covered by
          this description.

The two-colons form is used by _cvs to narrow the $words array before
calling _cvs_commands.  Thus the completers for each of the sub-commands
can pretend that the sub-command name is "in the command position" for
purposes of completing the options and arguments of that sub-command.

The additional stuff in _cvs invokes cvs to generate the list of sub-
commands and their abbreviations.  This is a fairly recent change; look
at an older version of _cvs for an alternate scheme using associative
arrays, for cases where there isn't a way to automatically generate the
lists.  You'll need to find a version of _cvs from before Oct 4.

Of course auto-generating the list of sub-commands means that if cvs
adds a new subcommand, the completer will be able to complete the sub-
command name, but won't be able to complete any options or arguments of
that sub-command.  And if your version of cvs itself is old enough to
not support the --help-commands or --help-synonyms options, then _cvs
won't be able to complete any sub-command names at all.  There's always
a tradeoff.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net