Zsh Mailing List Archive
Messages sorted by:
Re: Writing multi-part command completion functions
- X-seq: zsh-workers 13093
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers <zsh-workers@xxxxxxxxxxxxxx>
- Subject: Re: Writing multi-part command completion functions
- Date: Thu, 26 Oct 2000 16:18:24 +0000
- In-reply-to: <20001026151229.1321.qmail@xxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <20001026151229.1321.qmail@xxxxxxxxxxxxxxxxxxxxxx>
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
There is already support for this in _arguments:
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
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
Bart Schaefer Brass Lantern Enterprises
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
Messages sorted by: