mirror of
git://git.code.sf.net/p/zsh/code
synced 2025-07-04 14:31:24 +02:00
850 lines
36 KiB
Text
850 lines
36 KiB
Text
texinode(Programmable Completion Using compctl)(Completion Widgets)(Zsh Line Editor)(Top)
|
|
chapter(Programmable Completion Using compctl)
|
|
cindex(completion, programmable)
|
|
cindex(completion, controlling)
|
|
ifzman(\
|
|
sect(Synopsis)
|
|
This version of zsh has two ways of performing completion of words on the
|
|
command line. New users of the shell may prefer to use the newer
|
|
and more powerful system based on shell functions; this is described in
|
|
zmanref(zshcompsys), and the basic shell mechanisms which support it are
|
|
described in zmanref(zshcompwid). This manual entry describes the older
|
|
tt(compctl) command.
|
|
)\
|
|
ifnzman(\
|
|
sect(Types of completion)
|
|
This version of zsh has two ways of performing completino of words on the
|
|
command line. New users of the shell may prefer to use the newer
|
|
and more powerful system based on shell functions; this is described
|
|
in noderef(Completion System), and the basic shell mechanisms which support
|
|
it are described in noderef(Completion Widgets). This chapter describes
|
|
the older tt(compctl) command.
|
|
)\
|
|
findex(compctl)
|
|
sect(Description)
|
|
startlist()
|
|
list(tt(compctl) [ tt(-CDT) ] var(options) [ var(command) ... ])
|
|
list(tt(compctl) [ tt(-CDT) ] var(options) \
|
|
[ tt(-x) var(pattern) var(options) tt(-) ... tt(--) ] \
|
|
[ tt(PLUS()) var(options) [ tt(-x) ... tt(--) ] ... [tt(PLUS())] ] \
|
|
[ var(command) ... ])
|
|
list(tt(compctl) tt(-M) var(match-specs) ...)
|
|
list(tt(compctl) tt(-L) [ tt(-CDTM) ] [ var(command) ... ])
|
|
list(tt(compctl) tt(PLUS()) var(command) ...)
|
|
endlist()
|
|
|
|
Control the editor's completion behavior according to the supplied set
|
|
of var(options). Various editing commands, notably
|
|
tt(expand-or-complete-word), usually bound to tab, will
|
|
attempt to complete a word typed by the user, while others, notably
|
|
tt(delete-char-or-list), usually bound to ^D in EMACS editing
|
|
mode, list the possibilities; tt(compctl) controls what those
|
|
possibilities are. They may for example be filenames (the most common
|
|
case, and hence the default), shell variables, or words from a
|
|
user-specified list.
|
|
startmenu()
|
|
menu(Command Flags)
|
|
menu(Option Flags)
|
|
menu(Alternative Completion)
|
|
menu(Extended Completion)
|
|
menu(Matching Control)
|
|
menu(Example)
|
|
endmenu()
|
|
|
|
texinode(Command Flags)(Option Flags)()(Programmable Completion Using compctl)
|
|
sect(Command Flags)
|
|
Completion of the arguments of a command may be different for each
|
|
command or may use the default. The behavior when completing the
|
|
command word itself may also be separately specified. These
|
|
correspond to the following flags and arguments, all of which (except
|
|
for tt(-L)) may be combined with any combination of the
|
|
var(options) described subsequently in noderef(Option Flags):
|
|
|
|
startitem()
|
|
item(var(command) ...)(
|
|
controls completion for the named commands, which must be listed last
|
|
on the command line. If completion is attempted for a command with a
|
|
pathname containing slashes and no completion definition is found, the
|
|
search is retried with the last pathname component. If the command starts
|
|
with a tt(=), completion is tried with the pathname of the command.
|
|
|
|
Any of the var(command) strings may be patterns of the form normally
|
|
used for filename generation. These should be be quoted to protect them
|
|
from immediate expansion; for example the command string tt('foo*')
|
|
arranges for completion of the words of any command beginning with
|
|
tt(foo). When completion is attempted, all pattern completions are
|
|
tried in the reverse order of their definition until one matches. By
|
|
default, completion then proceeds as normal, i.e. the shell will try to
|
|
generate more matches for the specific command on the command line; this
|
|
can be overridden by including tt(-tn) in the flags for the pattern
|
|
completion.
|
|
|
|
Note that aliases
|
|
are expanded before the command name is determined unless the
|
|
tt(COMPLETE_ALIASES) option is set. Commands may not be combined
|
|
with the tt(-C), tt(-D) or tt(-T) flags.
|
|
)
|
|
item(tt(-C))(
|
|
controls completion when the command word itself is being completed.
|
|
If no tt(compctl -C) command has been issued, the names of any
|
|
executable command (whether in the path or specific to the shell, such
|
|
as aliases or functions) are completed.
|
|
)
|
|
item(tt(-D))(
|
|
controls default completion behavior for the arguments of commands not
|
|
assigned any special behavior. If no tt(compctl -D) command has
|
|
been issued, filenames are completed.
|
|
)
|
|
item(tt(-T))(
|
|
supplies completion flags to be used before any other processing is
|
|
done, even before processing for tt(compctl)s defined for specific
|
|
commands. This is especially useful when combined with extended
|
|
completion (the tt(-x) flag, see noderef(Extended Completion) below).
|
|
Using this flag you can define default behavior
|
|
which will apply to all commands without exception, or you can alter
|
|
the standard behavior for all commands. For example, if your access
|
|
to the user database is too slow and/or it contains too many users (so
|
|
that completion after `tt(~)' is too slow to be usable), you can use
|
|
|
|
example(compctl -T -x 's[~] C[0,[^/]#]' -k friends -S/ -tn)
|
|
|
|
to complete the strings in the array tt(friends) after a `tt(~)'.
|
|
The tt(C[...]) argument is necessary so that this form of ~-completion is
|
|
not tried after the directory name is finished.
|
|
)
|
|
item(tt(-L))(
|
|
lists the existing completion behavior in a manner suitable for
|
|
putting into a start-up script; the existing behavior is not changed.
|
|
Any combination of the above forms, or the tt(-M) flag (which must
|
|
follow the tt(-L) flag), may be specified, otherwise all defined
|
|
completions are listed. Any other flags supplied are ignored.
|
|
)
|
|
item(em(no argument))(
|
|
If no argument is given, tt(compctl) lists all defined completions
|
|
in an abbreviated form; with a list of var(options), all completions
|
|
with those flags set (not counting extended completion) are listed.
|
|
)
|
|
endlist()
|
|
|
|
If the tt(PLUS()) flag is alone and followed immediately by the var(command)
|
|
list, the completion behavior for all the commands in the list is reset to
|
|
the default. In other words, completion will subsequently use the
|
|
options specified by the tt(-D) flag.
|
|
|
|
The form with tt(-M) as the first and only option defines global
|
|
matching specifications, as described below in noderef(Matching Control).
|
|
|
|
texinode(Option Flags)(Alternative Completion)(Command Flags)(Programmable Completion Using compctl)
|
|
sect(Option Flags)
|
|
startlist()
|
|
list([ tt(-fcFBdeaRGovNAIOPZEnbjrzu/) ])
|
|
list([ tt(-k) var(array) ] [ tt(-g) var(globstring) ] \
|
|
[ tt(-s) var(subststring) ])
|
|
list([ tt(-K) var(function) ] [ tt(-i) var(function) ])
|
|
list([ tt(-Q) ] [ tt(-P) var(prefix) ] [ tt(-S) var(suffix) ])
|
|
list([ tt(-W) var(file-prefix) ] [ tt(-H) var(num pattern) ])
|
|
list([ tt(-q) ] [ tt(-X) var(explanation) ] [ tt(-Y) var(explanation) ])
|
|
list([ tt(-y) var(func-or-var) ] [ tt(-l) var(cmd) ] [ tt(-h) var(cmd) ] [ tt(-U) ])
|
|
list([ tt(-t) var(continue) ] [ tt(-J) var(name) ] [ tt(-V) var(name) ])
|
|
list([ tt(-M) var(match-spec) ])
|
|
endlist()
|
|
|
|
The remaining var(options) specify the type of command arguments
|
|
to look for during completion. Any combination of these flags may be
|
|
specified; the result is a sorted list of all the possibilities. The
|
|
options are as follows.
|
|
startmenu()
|
|
menu(Simple Flags)
|
|
menu(Flags with Arguments)
|
|
menu(Control Flags)
|
|
endmenu()
|
|
|
|
texinode(Simple Flags)(Flags with Arguments)()(Option Flags)
|
|
subsect(Simple Flags)
|
|
These produce completion lists made up by the shell itself:
|
|
|
|
startitem()
|
|
item(tt(-f))(
|
|
Filenames and filesystem paths.
|
|
)
|
|
item(tt(-/))(
|
|
Just filesystem paths.
|
|
)
|
|
item(tt(-c))(
|
|
Command names, including aliases, shell functions, builtins
|
|
and reserved words.
|
|
)
|
|
item(tt(-F))(
|
|
Function names.
|
|
)
|
|
item(tt(-B))(
|
|
Names of builtin commands.
|
|
)
|
|
item(tt(-m))(
|
|
Names of external commands.
|
|
)
|
|
item(tt(-w))(
|
|
Reserved words.
|
|
)
|
|
item(tt(-a))(
|
|
Alias names.
|
|
)
|
|
item(tt(-R))(
|
|
Names of regular (non-global) aliases.
|
|
)
|
|
item(tt(-G))(
|
|
Names of global aliases.
|
|
)
|
|
item(tt(-d))(
|
|
This can be combined with tt(-F), tt(-B), tt(-w),
|
|
tt(-a), tt(-R) and tt(-G) to get names of disabled
|
|
functions, builtins, reserved words or aliases.
|
|
)
|
|
item(tt(-e))(
|
|
This option (to show enabled commands) is in effect by default, but
|
|
may be combined with tt(-d); tt(-de) in combination with
|
|
tt(-F), tt(-B), tt(-w), tt(-a), tt(-R) and tt(-G)
|
|
will complete names of functions, builtins, reserved words or aliases
|
|
whether or not they are disabled.
|
|
)
|
|
item(tt(-o))(
|
|
Names of shell options (see
|
|
ifzman(zmanref(zshoptions))\
|
|
ifnzman(noderef(Options))\
|
|
).
|
|
)
|
|
item(tt(-v))(
|
|
Names of any variable defined in the shell.
|
|
)
|
|
item(tt(-N))(
|
|
Names of scalar (non-array) parameters.
|
|
)
|
|
item(tt(-A))(
|
|
Array names.
|
|
)
|
|
item(tt(-I))(
|
|
Names of integer variables.
|
|
)
|
|
item(tt(-O))(
|
|
Names of read-only variables.
|
|
)
|
|
item(tt(-p))(
|
|
Names of parameters used by the shell (including special parameters).
|
|
)
|
|
item(tt(-Z))(
|
|
Names of shell special parameters.
|
|
)
|
|
item(tt(-E))(
|
|
Names of environment variables.
|
|
)
|
|
item(tt(-n))(
|
|
Named directories.
|
|
)
|
|
item(tt(-b))(
|
|
Key binding names.
|
|
)
|
|
item(tt(-j))(
|
|
Job names: the first word of the job leader's command line. This is useful
|
|
with the tt(kill) builtin.
|
|
)
|
|
item(tt(-r))(
|
|
Names of running jobs.
|
|
)
|
|
item(tt(-z))(
|
|
Names of suspended jobs.
|
|
)
|
|
item(tt(-u))(
|
|
User names.
|
|
)
|
|
enditem()
|
|
|
|
texinode(Flags with Arguments)(Control Flags)(Simple Flags)(Option Flags)
|
|
subsect(Flags with Arguments)
|
|
These have user supplied arguments to determine how the list of
|
|
completions is to be made up:
|
|
|
|
startitem()
|
|
item(tt(-k) var(array))(
|
|
Names taken from the elements of tt($)var(array) (note that the `tt($)'
|
|
does not appear on the command line).
|
|
Alternatively, the argument var(array) itself may be a set
|
|
of space- or comma-separated values in parentheses, in which any
|
|
delimiter may be escaped with a backslash; in this case the argument
|
|
should be quoted. For example,
|
|
|
|
example(compctl -k "(cputime filesize datasize stacksize
|
|
coredumpsize resident descriptors)" limit)
|
|
)
|
|
item(tt(-g) var(globstring))(
|
|
The var(globstring) is expanded using filename globbing; it should be
|
|
quoted to protect it from immediate expansion. The resulting
|
|
filenames are taken as the possible completions. Use `tt(*(/))' instead of
|
|
`tt(*/)' for directories. The tt(fignore) special parameter is not
|
|
applied to the resulting files. More than one pattern may be given
|
|
separated by blanks. (Note that brace expansion is em(not) part of
|
|
globbing. Use the syntax `tt((either|or))' to match alternatives.)
|
|
)
|
|
item(tt(-s) var(subststring))(
|
|
The var(subststring) is split into words and these words are than
|
|
expanded using all shell expansion mechanisms (see
|
|
ifzman(zmanref(zshexpn))\
|
|
ifnzman(noderef(Expansion))\
|
|
). The resulting words are taken as possible
|
|
completions. The tt(fignore) special parameter is not applied to the
|
|
resulting files. Note that tt(-g) is faster for filenames.
|
|
)
|
|
item(tt(-K) var(function))(
|
|
Call the given function to get the completions. Unless the name
|
|
starts with an underscore, the function is
|
|
passed two arguments: the prefix and the suffix of the word on which
|
|
completion is to be attempted, in other words those characters before
|
|
the cursor position, and those from the cursor position onwards. The
|
|
whole command line can be accessed with the tt(-c) and tt(-l) flags
|
|
of the tt(read) builtin. The
|
|
function should set the variable tt(reply) to an array containing
|
|
the completions (one completion per element); note that tt(reply)
|
|
should not be made local to the function. From such a function the
|
|
command line can be accessed with the tt(-c) and tt(-l) flags to
|
|
the tt(read) builtin. For example,
|
|
|
|
example(function whoson { reply=(`users`); }
|
|
compctl -K whoson talk)
|
|
|
|
completes only logged-on users after `tt(talk)'. Note that `tt(whoson)' must
|
|
return an array, so `tt(reply=`users`)' would be incorrect.
|
|
)
|
|
item(tt(-i) var(function))(
|
|
Like tt(-K), but the function is invoked in a context like that for
|
|
completion widgets, see
|
|
ifzman(zmanref(zshzle))\
|
|
ifnzman(noderef(The zle Module))\
|
|
for more information.
|
|
)
|
|
item(tt(-H) var(num pattern))(
|
|
The possible completions are taken from the last var(num) history
|
|
lines. Only words matching var(pattern) are taken. If var(num) is
|
|
zero or negative the whole history is searched and if var(pattern) is
|
|
the empty string all words are taken (as with `tt(*)'). A typical
|
|
use is
|
|
|
|
example(compctl -D -f PLUS() -H 0 '')
|
|
|
|
which forces completion to look back in the history list for a word if
|
|
no filename matches.
|
|
)
|
|
enditem()
|
|
|
|
texinode(Control Flags)()(Flags with Arguments)(Option Flags)
|
|
subsect(Control Flags)
|
|
These do not directly specify types of name to be completed, but
|
|
manipulate the options that do:
|
|
|
|
startitem()
|
|
item(tt(-Q))(
|
|
This instructs the shell not to quote any metacharacters in the possible
|
|
completions. Normally the results of a completion are inserted into
|
|
the command line with any metacharacters quoted so that they are
|
|
interpreted as normal characters. This is appropriate for filenames
|
|
and ordinary strings. However, for special effects, such as inserting
|
|
a backquoted expression from a completion array (tt(-k)) so that
|
|
the expression will not be evaluated until the complete line is
|
|
executed, this option must be used.
|
|
)
|
|
item(tt(-P) var(prefix))(
|
|
The var(prefix) is inserted just before the completed string; any
|
|
initial part already typed will be completed and the whole var(prefix)
|
|
ignored for completion purposes. For example,
|
|
|
|
example(compctl -j -P "%" kill)
|
|
|
|
inserts a `%' after the kill command and then completes job names.
|
|
)
|
|
item(tt(-S) var(suffix))(
|
|
When a completion is found the var(suffix) is inserted after
|
|
the completed string. In the case of menu completion the suffix is
|
|
inserted immediately, but it is still possible to cycle through the
|
|
list of completions by repeatedly hitting the same key.
|
|
)
|
|
item(tt(-W) var(file-prefix))(
|
|
With directory var(file-prefix): for command, file, directory and
|
|
globbing completion (options tt(-c), tt(-f), tt(-/), tt(-g)), the file
|
|
prefix is implicitly added in front of the completion. For example,
|
|
|
|
example(compctl -/ -W ~/Mail maildirs)
|
|
|
|
completes any subdirectories to any depth beneath the directory
|
|
tt(~/Mail), although that prefix does not appear on the command line.
|
|
The var(file-prefix) may also be of the form accepted by the tt(-k)
|
|
flag, i.e. the name of an array or a literal list in parenthesis. In
|
|
this case all the directories in the list will be searched for
|
|
possible completions.
|
|
)
|
|
item(tt(-q))(
|
|
If used with a suffix as specified by the tt(-S) option, this
|
|
causes the suffix to be removed if the next character typed is a blank
|
|
or does not insert anything or if the suffix consists of only one character
|
|
and the next character typed is the same character; this the same rule used
|
|
for the tt(AUTO_REMOVE_SLASH) option. The option is most useful for list
|
|
separators (comma, colon, etc.).
|
|
)
|
|
item(tt(-l) var(cmd))(
|
|
This option restricts the range
|
|
of command line words that are considered to be arguments. If
|
|
combined with one of the extended completion patterns `tt(p[)...tt(])',
|
|
`tt(r[)...tt(])', or `tt(R[)...tt(])' (see noderef(Extended Completion)
|
|
below) the range is restricted to the range of arguments
|
|
specified in the brackets. Completion is then performed as if these
|
|
had been given as arguments to the var(cmd) supplied with the
|
|
option. If the var(cmd) string is empty the first word in the range
|
|
is instead taken as the command name, and command name completion
|
|
performed on the first word in the range. For example,
|
|
|
|
example(compctl -x 'r[-exec,;]' -l '' -- find)
|
|
|
|
completes arguments between `tt(-exec)' and the following `tt(;)' (or the end
|
|
of the command line if there is no such string) as if they were
|
|
a separate command line.
|
|
)
|
|
item(tt(-h) var(cmd))(
|
|
Normally zsh completes quoted strings as a whole. With this option,
|
|
completion can be done separately on different parts of such
|
|
strings. It works like the tt(-l) option but makes the completion code
|
|
work on the parts of the current word that are separated by
|
|
spaces. These parts are completed as if they were arguments to the
|
|
given var(cmd). If var(cmd) is the empty string, the first part is
|
|
completed as a command name, as with tt(-l).
|
|
)
|
|
item(tt(-U))(
|
|
Use the whole list of possible completions, whether or not they
|
|
actually match the word on the command line. The word typed so far
|
|
will be deleted. This is most useful with a function (given by the
|
|
tt(-K) option) which can examine the word components passed to it
|
|
(or via the tt(read) builtin's tt(-c) and tt(-l) flags) and
|
|
use its own criteria to decide what matches. If there is no
|
|
completion, the original word is retained. Since the produced
|
|
possible completions seldom seldom have interesting common prefixes
|
|
and suffixes, menucompletion is started immediately if tt(AUTO_MENU) is
|
|
set and this flag is used.
|
|
)
|
|
item(tt(-y) var(func-or-var))(
|
|
The list provided by var(func-or-var) is displayed instead of the list
|
|
of completions whenever a listing is required; the actual completions
|
|
to be inserted are not affected. It can be provided in two
|
|
ways. Firstly, if var(func-or-var) begins with a tt($) it defines a
|
|
variable, or if it begins with a left parenthesis a literal
|
|
array, which contains the list. A variable may have been set by a
|
|
call to a function using the tt(-K) option. Otherwise it contains the
|
|
name of a function which will be executed to create the list. The
|
|
function will be passed as an argument list all matching completions,
|
|
including prefixes and suffixes expanded in full, and should set the
|
|
array var(reply) to the result. In both cases, the display list will
|
|
only be retrieved after a complete list of matches has been created.
|
|
|
|
Note that the returned list does not have to correspond, even in
|
|
length, to the original set of matches, and may be passed as a scalar
|
|
instead of an array. No special formatting of characters is
|
|
performed on the output in this case; in particular, newlines are
|
|
printed literally and if they appear output in columns is suppressed.
|
|
)
|
|
item(tt(-X) var(explanation))(
|
|
Print var(explanation) when trying completion on the current set of
|
|
options. A `tt(%n)' in this string is replaced by the number of
|
|
matches that were added for this explanation string.
|
|
The explanation only appears if completion was tried and there was
|
|
no unique match, or when listing completions. Explanation strings
|
|
will be listed together with the matches of the group specified
|
|
together with the tt(-X) option (using the tt(-J) or tt(-V)
|
|
option). If the same explanation string is given to multiple tt(-X)
|
|
options, the string appears only once (for each group) and the number
|
|
of matches shown for the `tt(%n)' is the total number of all matches
|
|
for each of these uses. In any case, the explanation string will only
|
|
be shown if there was at least one match added for the explanation
|
|
string.
|
|
|
|
The sequences tt(%B), tt(%b), tt(%S), tt(%s), tt(%U), and tt(%u) specify
|
|
output attributes (bold, standout, and underline) and tt(%{...%}) can
|
|
be used to include literal escape sequences as in prompts.
|
|
)
|
|
item(tt(-Y) var(explanation))(
|
|
Identical to tt(-X), except that the var(explanation) first undergoes
|
|
expansion following the usual rules for strings in double quotes.
|
|
The expansion will be carried out after any functions are called for
|
|
the tt(-K) or tt(-y) options, allowing them to set variables.
|
|
)
|
|
item(tt(-t) var(continue))(
|
|
The var(continue)-string contains a character that specifies which set
|
|
of completion flags should be used next. It is useful:
|
|
|
|
(i) With tt(-T), or when trying a list of pattern completions, when
|
|
tt(compctl) would usually continue with ordinary processing after
|
|
finding matches; this can be suppressed with `tt(-tn)'.
|
|
|
|
(ii) With a list of alternatives separated by tt(+), when tt(compctl)
|
|
would normally stop when one of the alternatives generates matches. It
|
|
can be forced to consider the next set of completions by adding `tt(-t+)'
|
|
to the flags of the alternative before the `tt(+)'.
|
|
|
|
(iii) In an extended completion list (see below), when tt(compctl) would
|
|
normally continue until a set of conditions succeeded, then use only
|
|
the immediately following flags. With `tt(-t-)', tt(compctl) will
|
|
continue trying extended completions after the next `tt(-)'; with
|
|
`tt(-tx)' it will attempt completion with the default flags, in other
|
|
words those before the `tt(-x)'.
|
|
)
|
|
item(tt(-J) var(name))(
|
|
This gives the name of the group the matches should be placed in. Groups
|
|
are listed and sorted separately; likewise, menucompletion will offer
|
|
the matches in the groups in the order in which the groups were
|
|
defined. If no group name is explicitly given, the matches are stored in
|
|
a group named var(default). The first time a group name is encountered,
|
|
a group with that name is created. After that all matches with the same
|
|
group name are stored in that group.
|
|
|
|
This can be useful with non-exclusive alternative completions. For
|
|
example, in
|
|
|
|
example(compctl -f -J files -t+ + -v -J variables foo)
|
|
|
|
both files and variables are possible completions, as the tt(-t+) forces
|
|
both sets of alternatives before and after the tt(+) to be considered at
|
|
once. Because of the tt(-J) options, however, all files are listed
|
|
before all variables.
|
|
)
|
|
item(tt(-V) var(name))(
|
|
Like tt(-J), but matches within the group will not be sorted in listings
|
|
nor in menucompletion. These unsorted groups are in a different name
|
|
space than the sorted ones, so groups defined as tt(-J files) and tt(-V
|
|
files) are distinct.
|
|
)
|
|
item(tt(-M) var(match-spec))(
|
|
This defines additional matching control specifications that should be used
|
|
only when testing words for the list of flags this flag appears in. The format
|
|
of the var(match-spec) string is described below in noderef(Matching Control).
|
|
)
|
|
enditem()
|
|
|
|
texinode(Alternative Completion)(Extended Completion)(Option Flags)(Programmable Completion Using compctl)
|
|
sect(Alternative Completion)
|
|
startlist()
|
|
list(tt(compctl) [ tt(-CDT) ] var(options) tt(PLUS()) var(options) [ tt(PLUS()) ... ] \
|
|
[ tt(PLUS()) ] var(command) ...)
|
|
endlist()
|
|
|
|
The form with `tt(PLUS())' specifies alternative options. Completion is
|
|
tried with the options before the first `tt(PLUS())'. If this produces no
|
|
matches completion is tried with the flags after the `tt(PLUS())' and so on. If
|
|
there are no flags after the last `tt(PLUS())' and a match has not been found
|
|
up to that point, default completion is tried.
|
|
If the list of flags contains a tt(-t) with a tt(PLUS()) character, the next
|
|
list of flags is used even if the current list produced matches.
|
|
|
|
texinode(Extended Completion)(Matching Control)(Alternative Completion)(Programmable Completion Using compctl)
|
|
sect(Extended Completion)
|
|
startlist()
|
|
list(nofill(tt(compctl) [ tt(-CDT) ] var(options) \
|
|
tt(-x) var(pattern) var(options) tt(-) ... tt(--)
|
|
[ var(command) ... ]))
|
|
list(nofill(tt(compctl) [ tt(-CDT) ] var(options) \
|
|
[ tt(-x) var(pattern) var(options) tt(-) ... tt(--) ]
|
|
[ tt(PLUS()) var(options) [ tt(-x) ... tt(--) ] ... [tt(PLUS())] ] \
|
|
[ var(command) ... ]))
|
|
endlist()
|
|
|
|
The form with `tt(-x)' specifies extended completion for the
|
|
commands given; as shown, it may be combined with alternative
|
|
completion using `tt(PLUS())'. Each var(pattern) is examined in turn; when a
|
|
match is found, the corresponding var(options), as described in
|
|
noderef(Option Flags) above, are used to generate possible
|
|
completions. If no var(pattern) matches, the var(options) given
|
|
before the tt(-x) are used.
|
|
|
|
Note that each pattern should be supplied as a single argument and
|
|
should be quoted to prevent expansion of metacharacters by the
|
|
shell.
|
|
|
|
A var(pattern) is built of sub-patterns separated by commas; it
|
|
matches if at least one of these sub-patterns matches (they are
|
|
`or'ed). These sub-patterns are in turn composed of other
|
|
sub-patterns separated by white spaces which match if all of the
|
|
sub-patterns match (they are `and'ed). An element of the
|
|
sub-patterns is of the form `var(c)tt([)...tt(][)...tt(])', where the pairs of
|
|
brackets may be repeated as often as necessary, and matches if any of
|
|
the sets of brackets match (an `or'). The example below makes this
|
|
clearer.
|
|
|
|
The elements may be any of the following:
|
|
|
|
startitem()
|
|
item(tt(s[)var(string)tt(])...)(
|
|
Matches if the current word on the command line starts with
|
|
one of the strings given in brackets. The var(string) is not removed
|
|
and is not part of the completion.
|
|
)
|
|
item(tt(S[)var(string)tt(])...)(
|
|
Like tt(s[)var(string)tt(]) except that the var(string) is part of the
|
|
completion.
|
|
)
|
|
item(tt(p[)var(from)tt(,)var(to)tt(])...)(
|
|
Matches if the number of the current word is between one of
|
|
the var(from) and var(to) pairs inclusive. The comma and var(to)
|
|
are optional; var(to) defaults to the same value as var(from). The
|
|
numbers may be negative: tt(-)var(n) refers to the var(n)'th last word
|
|
on the line.
|
|
)
|
|
item(tt(c[)var(offset)tt(,)var(string)tt(])...)(
|
|
Matches if the var(string) matches the word offset by
|
|
var(offset) from the current word position. Usually var(offset)
|
|
will be negative.
|
|
)
|
|
item(tt(C[)var(offset)tt(,)var(pattern)tt(])...)(
|
|
Like tt(c) but using pattern matching instead.
|
|
)
|
|
item(tt(w[)var(index)tt(,)var(string)tt(])...)(
|
|
Matches if the word in position var(index) is equal
|
|
to the corresponding var(string). Note that the word count is made
|
|
after any alias expansion.
|
|
)
|
|
item(tt(W[)var(index)tt(,)var(pattern)tt(])...)(
|
|
Like tt(w) but using pattern matching instead.
|
|
)
|
|
item(tt(n[)var(index)tt(,)var(string)tt(])...)(
|
|
Matches if the current word contains var(string). Anything up to and
|
|
including the var(index)th occurrence of this string will not be
|
|
considered part of the completion, but the rest will. var(index) may
|
|
be negative to count from the end: in most cases, var(index) will be
|
|
1 or -1. For example,
|
|
|
|
example(compctl -s '`users`' -x 'n[1,@]' -k hosts -- talk)
|
|
|
|
will usually complete usernames, but if you insert an tt(@) after the
|
|
name, names from the array var(hosts) (assumed to contain hostnames,
|
|
though you must make the array yourself) will be completed. Other
|
|
commands such as tt(rcp) can be handled similarly.
|
|
)
|
|
item(tt(N[)var(index)tt(,)var(string)tt(])...)(
|
|
Like tt(n) except that the string will be
|
|
taken as a character class. Anything up to and including the
|
|
var(index)th occurrence of any of the characters in var(string)
|
|
will not be considered part of the completion.
|
|
)
|
|
item(tt(m[)var(min)tt(,)var(max)tt(])...)(
|
|
Matches if the total number of words lies between var(min) and
|
|
var(max) inclusive.
|
|
)
|
|
item(tt(r[)var(str1)tt(,)var(str2)tt(])...)(
|
|
Matches if the cursor is after a word with prefix var(str1). If there
|
|
is also a word with prefix var(str2) on the command line it matches
|
|
only if the cursor is before this word. If the comma and var(str2) are
|
|
omitted, it matches if the cursor is after a word with prefix var(str1).
|
|
)
|
|
item(tt(R[)var(str1)tt(,)var(str2)tt(])...)(
|
|
Like tt(r) but using pattern matching instead.
|
|
)
|
|
item(tt(q[)var(str)tt(])...)(
|
|
Matches the word currently being completed is in single quotes and the
|
|
var(str) begins with the letter `s', or if completion is done in
|
|
double quotes and var(str) starts with the letter `d', or if
|
|
completion is done in backticks and var(str) starts with a `b'.
|
|
)
|
|
enditem()
|
|
|
|
texinode(Matching Control)(Example)(Extended Completion)(Programmable Completion Using compctl)
|
|
sect(Matching Control)
|
|
|
|
It is possible by use of the tt(-M) var(spec) flag to specify how the
|
|
characters in the string to be completed (referred to here as the
|
|
command line) map onto the characters in the list of matches produced by
|
|
the completion code (referred to here as the trial completions).
|
|
|
|
The var(spec) consists of one or more matching descriptions separated by
|
|
whitespace. Each description consists of a letter followed by a colon,
|
|
then the patterns describing which character sequences on the line match
|
|
which character sequences in the trial completion. Any sequence of characters not
|
|
handled in this fashion must match exactly, as usual.
|
|
|
|
The forms of var(spec) understood are as follows. In each case, the
|
|
form with an uppercase initial character retains the string already
|
|
typed on the command line as the final result of completion, while with
|
|
a lowercase initial character the string on the command line is changed
|
|
into the corresponding part of the trial completion.
|
|
|
|
startitem()
|
|
xitem(tt(m:)var(lpat)tt(=)var(tpat))
|
|
item(tt(M:)var(lpat)tt(=)var(tpat))(
|
|
Here, var(lpat) is a pattern that matches on the command line,
|
|
corresponding to var(tpat) which matches in the trial completion.
|
|
)
|
|
xitem(tt(l:)var(anchor)tt(|)var(lpat)tt(=)var(tpat))
|
|
item(tt(L:)var(anchor)tt(|)var(lpat)tt(=)var(tpat))(
|
|
These letters are for patterns that are anchored by another pattern on
|
|
the left side. Matching for var(lpat) and var(tpat) is as for tt(m) and
|
|
tt(M), but the pattern var(lpat) matched on the command line must be
|
|
preceeded by the pattern var(anchor). The var(anchor) can be blank to
|
|
anchor the match to the start of the command line string; otherwise the
|
|
anchor can occur anywhere, but must match in both the command line and
|
|
trial completion strings.
|
|
)
|
|
xitem(tt(r:)var(lpat)tt(|)var(anchor)tt(=)var(tpat))
|
|
item(tt(R:)var(lpat)tt(|)var(anchor)tt(=)var(tpat))(
|
|
As tt(l) and tt(L) with the difference that the command line and trial
|
|
completion patterns are anchored on the right side. Here an empty
|
|
var(anchor) forces the match to the end of the command line string.
|
|
)
|
|
enditem()
|
|
|
|
Each var(lpat), var(tpat) or var(anchor) is either an empty string or
|
|
consists of a sequence of literal characters (which may be quoted with a
|
|
backslash), question marks, character classes, and correspondence
|
|
classes; ordinary shell patterns are not used. Literal characters match
|
|
only themselves, question marks match any character, and character
|
|
classes are formed as for globbing and match any character in the given
|
|
set.
|
|
|
|
Correspondence classes are defined like character classes, but with two
|
|
differences: they are delimited by a pair of braces, and negated classes
|
|
are not allowed, so the characters tt(!) and tt(^) have no special
|
|
meaning directly after the opening brace. They indicate that a range of
|
|
characters on the line match a range of characters in the trial
|
|
completion, but (unlike ordinary character classes) paired according to
|
|
the corresponding position in the sequence. For example, to make any
|
|
lowercase letter on the line match the corresponding uppercase letter in
|
|
the trial completion, you can use `tt(m:{a-z}={A-Z})'. More than one
|
|
pair of classes can occur, in which case the first class before the
|
|
tt(=) corresponds to the first after it, and so on. If one side has
|
|
more such classes than the other side, the superfluous classes behave
|
|
like normal character classes. In anchor patterns correspondence classes
|
|
also behave like normal character classes.
|
|
|
|
The pattern var(tpat) may also be a single star, `tt(*)'. This means
|
|
that the pattern on the command line can match any number of characters
|
|
in the trial completion. In this case the pattern must be anchored (on
|
|
either side); the var(anchor) then determines how much of the trial
|
|
completion is to be included --- only the characters up to the next
|
|
appearance of the anchor will be matched.
|
|
|
|
Examples:
|
|
|
|
The option tt(-o) produces option names in all-lowercase form, without
|
|
underscores, and without the optional tt(no) at the beginning even
|
|
though the builtins tt(setopt) and tt(unsetopt) understand option names
|
|
with uppercase letters, underscores, and the optional tt(no). The
|
|
following alters the matching rules so that the prefix tt(no) and any
|
|
underscore are ignored when trying to match the trial completions
|
|
generated and uppercase letters on the line match the corresponding
|
|
lowercase letters in the words:
|
|
|
|
example(compctl -M 'L:|[nN][oO]= M:_= M:{A-Z}={a-z}' \
|
|
-o setopt unsetopt)
|
|
|
|
The first part says that the pattern `tt([nN][oO])' at the beginning
|
|
(the empty anchor before the pipe symbol) of the string on the
|
|
line matches the empty string in the list of words generated by
|
|
completion, so it will be ignored if present. The second part does the
|
|
same for an underscore anywhere in the command line string, and the
|
|
third part uses correspondence classes so that any
|
|
uppercase letter on the line matches the corresponding lowercase
|
|
letter in the word. The use of the uppercase forms of the
|
|
specification characters (tt(L) and tt(M)) guarantees that what has
|
|
already been typed on the command line (in particular the prefix
|
|
tt(no)) will not be deleted.
|
|
|
|
The second example makes completion case insensitive. By using
|
|
tt(compctl) with the tt(-M) option alone this applies to every
|
|
completion. This is just the same as in the tt(setopt) example, except
|
|
here we wish to retain the characters in the list of completions:
|
|
|
|
example(compctl -M 'm:{a-z}={A-Z}')
|
|
|
|
This makes lowercase letters match their uppercase counterparts.
|
|
To make uppercase letters match the lowercase forms as well:
|
|
|
|
example(compctl -M 'm:{a-zA-Z}={A-Za-z}')
|
|
|
|
A nice example for the use of tt(*) patterns is partial word
|
|
completion. Sometimes you would like to make strings like tt(c.s.u)
|
|
complete to strings like tt(comp.source.unix), i.e. the word on the
|
|
command line consists of multiple parts, separated by a dot in this
|
|
example, where each part should be completed separately --- note,
|
|
however, that the case where each part of the word, i.e. tt(comp),
|
|
tt(source) and tt(unix) in this example, is to be completed separately
|
|
is a different problem to be solved by extended completion. The
|
|
example can be handled by:
|
|
|
|
example(compctl -M 'r:|.=* r:|=*' \
|
|
-k '(comp.sources.unix comp.sources.misc ...)' ngroups)
|
|
|
|
The first specification says that tt(lpat) is the empty string, while
|
|
tt(anchor) is a dot; tt(tpat) is tt(*), so this can match anything
|
|
except for the `tt(.)' from the anchor in
|
|
the trial completion word. So in tt(c.s.u), the matcher sees tt(c),
|
|
followed by the empty string, followed by the anchor `tt(.)', and
|
|
likewise for the second dot, and replaces the empty strings before the
|
|
anchors, giving tt(c)[tt(omp)]tt(.s)[tt(ources)]tt(.u)[tt(nix)], where
|
|
the last part of the completion is just as normal.
|
|
|
|
The second specification is needed to make this work when the cursor is
|
|
in the middle of the string on the command line and the option
|
|
tt(COMPLETE_IN_WORD) is set. In this case the completion code would
|
|
normally try to match trial completions that end with the string as
|
|
typed so far, i.e. it will only insert new characters at the cursor
|
|
position rather then at the end. However in our example we would like
|
|
the code to recognise matches which contain extra characters after the
|
|
string on the line (the tt(nix) in the example). Hence we say that the
|
|
empty string at the end of the string on the line matches any characters
|
|
at the end of the trial completion.
|
|
|
|
More generally, the specification
|
|
|
|
example(compctl -M 'r:|[.,_-]=* r:|=*')
|
|
|
|
allows one to complete words with abbreviations before any of the
|
|
characters in the square brackets in any completion. For example, to
|
|
complete tt(veryverylongfile.c) rather than tt(veryverylongheader.h)
|
|
with the above in effect, you can just type tt(very.c) before attempting
|
|
completion.
|
|
|
|
The form tt(compctl -M) that defines global matching actually accepts
|
|
any number of specification strings, unlike the case where the tt(-M)
|
|
option applies only to a particular command. In this case, when
|
|
completion is attempted for any command, the code will try the
|
|
specifications in order until one matches. This allows one to define
|
|
simple and fast matches to be used first, more powerful matchers as a
|
|
second choice, and so on.
|
|
|
|
For example, one can make the code match trial completions that contain
|
|
the string on the command line as a substring, not just at the
|
|
beginning. Since this might produce more matches than we want,
|
|
we arrange for it to be tried only if the matchers described above don't
|
|
produce any matches:
|
|
|
|
example(compctl -M 'r:|[.,_-]=* r:|=*' 'l:|=* r:|=*')
|
|
|
|
Here, if the string on the command line is tt(foo.bar), tt(compctl)
|
|
first tries matching tt(foo)var(anything)tt(.bar)var(anything), as
|
|
with the previous example. If that fails, the two descriptions in the
|
|
second string after the tt(-M) say that the blanks at the beginning
|
|
and end of the string on the command line can match any set of
|
|
characters at the beginning or end of the trial completion, so it will
|
|
look for var(anything)tt(foo.bar)var(anything).
|
|
|
|
texinode(Example)()(Matching Control)(Programmable Completion Using compctl)
|
|
sect(Example)
|
|
|
|
example(compctl -u -x 's[tt(PLUS())] c[-1,-f],s[-f+PLUS()]' \
|
|
-g '~/Mail/*(:t)' - 's[-f],c[-1,-f]' -f -- mail)
|
|
|
|
This is to be interpreted as follows:
|
|
|
|
If the current command is tt(mail), then
|
|
|
|
indent(
|
|
if ((the current word begins with tt(PLUS()) and the previous word is tt(-f))
|
|
or (the current word begins with tt(-f+PLUS()))), then complete the
|
|
non-directory part (the `tt(:t)' glob modifier) of files in the directory
|
|
tt(~/Mail); else
|
|
|
|
if the current word begins with tt(-f) or the previous word was tt(-f), then
|
|
complete any file; else
|
|
|
|
complete user names.
|
|
)
|