zshcompsys
ZSHCOMPSYS(1) ZSHCOMPSYS(1)
NAME
zshcompsys - zsh completion system
DESCRIPTION
This describes the shell code for the new completion system. It con-
sists of various shell functions; those beginning ‘comp’ are to be
called directly, while those beginning ‘_’ are called by the completion
code. The shell functions of the second set, which implement comple-
tion behaviour and may be bound to keystrokes, are referred to as ‘wid-
gets’.
INITIALIZATION
If the system was installed completely, it should be enough to call the
shell function compinit from your initialization file; see the next
section. However, the function compinstall can be run by a user to
configure various aspects of the completion system.
Usually, compinstall will insert code into .zshrc, although if that is
not writable it will save it in another file and tell you that file’s
location. Note that it is up to you to make sure that the lines added
to .zshrc are actually run; you may, for example, need to move them to
an earlier place in the file if .zshrc usually returns early. So long
as you keep them all together (including the comment lines at the start
and finish), you can rerun compinstall and it will correctly locate and
modify these lines. Note, however, that any code you add to this sec-
tion by hand is likely to be lost if you rerun compinstall, although
lines using the command ‘zstyle’ should be gracefully handled.
The new code will take effect next time you start the shell, or run
.zshrc by hand; there is also an option to make them take effect imme-
diately. However, if compinstall has removed definitions, you will
need to restart the shell to see the changes.
To run compinstall you will need to make sure it is in a directory men-
tioned in your fpath parameter, which should already be the case if zsh
was properly configured as long as your startup files do not remove the
appropriate directories from fpath. Then it must be autoloaded
(‘autoload -U compinstall’ is recommended). You can abort the instal-
lation any time you are being prompted for information, and your .zshrc
will not be altered at all; changes only take place right at the end,
where you are specifically asked for confirmation.
Use of compinit
This section describes the use of compinit to initialize completion for
the current session when called directly; if you have run compinstall
it will be called automatically from your .zshrc.
To initialize the system, the function compinit should be in a direc-
tory mentioned in the fpath parameter, and should be autoloaded
(‘autoload -U compinit’ is recommended), and then run simply as
‘compinit’. This will define a few utility functions, arrange for all
the necessary shell functions to be autoloaded, and will then re-define
all widgets that do completion to use the new system. If you use the
menu-select widget, which is part of the zsh/complist module, you
should make sure that that module is loaded before the call to compinit
so that that widget is also re-defined. If completion styles (see
below) are set up to perform expansion as well as completion by
default, and the TAB key is bound to expand-or-complete, compinit will
rebind it to complete-word; this is necessary to use the correct form
of expansion.
Should you need to use the original completion commands, you can still
bind keys to the old widgets by putting a ‘.’ in front of the widget
name, e.g. ‘.expand-or-complete’.
To speed up the running of compinit, it can be made to produce a dumped
configuration that will be read in on future invocations; this is the
default, but can be turned off by calling compinit with the option -D.
The dumped file is .zcompdump in the same directory as the startup
files (i.e. $ZDOTDIR or $HOME); alternatively, an explicit file name
can be given by ‘compinit -d dumpfile’. The next invocation of
compinit will read the dumped file instead of performing a full ini-
tialization.
If the number of completion files changes, compinit will recognise this
and produce a new dump file. However, if the name of a function or the
arguments in the first line of a #compdef function (as described below)
change, it is easiest to delete the dump file by hand so that compinit
will re-create it the next time it is run. The check performed to see
if there are new functions can be omitted by giving the option -C. In
this case the dump file will only be created if there isn’t one
already.
The dumping is actually done by another function, compdump, but you
will only need to run this yourself if you change the configuration
(e.g. using compdef) and then want to dump the new one. The name of
the old dumped file will be remembered for this purpose.
If the parameter _compdir is set, compinit uses it as a directory where
completion functions can be found; this is only necessary if they are
not already in the function search path.
For security reasons compinit also checks if the completion system
would use files not owned by root or by the current user, or files in
directories that are world- or group-writable or that are not owned by
root or by the current user. If such files or directories are found,
compinit will ask if the completion system should really be used. To
avoid these tests and make all files found be used without asking, use
the option -u, and to make compinit silently ignore all insecure files
and directories use the option -i. This security check is skipped
entirely when the -C option is given.
The security check can be retried at any time by running the function
compaudit. This is the same check used by compinit, but when it is
executed directly any changes to fpath are made local to the function
so they do not persist. The directories to be checked may be passed as
arguments; if none are given, compaudit uses fpath and _compdir to find
completion system directories, adding missing ones to fpath as neces-
sary. To force a check of exactly the directories currently named in
fpath, set _compdir to an empty string before calling compaudit or
compinit.
Autoloaded files
The convention for autoloaded functions used in completion is that they
start with an underscore; as already mentioned, the fpath/FPATH parame-
ter must contain the directory in which they are stored. If zsh was
properly installed on your system, then fpath/FPATH automatically con-
tains the required directories for the standard functions.
For incomplete installations, if compinit does not find enough files
beginning with an underscore (fewer than twenty) in the search path, it
will try to find more by adding the directory _compdir to the search
path. If that directory has a subdirectory named Base, all subdirecto-
ries will be added to the path. Furthermore, if the subdirectory Base
has a subdirectory named Core, compinit will add all subdirectories of
the subdirectories is to the path: this allows the functions to be in
the same format as in the zsh source distribution.
When compinit is run, it searches all such files accessible via
fpath/FPATH and reads the first line of each of them. This line should
contain one of the tags described below. Files whose first line does
not start with one of these tags are not considered to be part of the
completion system and will not be treated specially.
The tags are:
#compdef names... [ -[pP] patterns... [ -N names... ] ]
The file will be made autoloadable and the function defined in
it will be called when completing names, each of which is either
the name of a command whose arguments are to be completed or one
of a number of special contexts in the form -context- described
below.
Each name may also be of the form ‘cmd=service’. When complet-
ing the command cmd, the function typically behaves as if the
command (or special context) service was being completed
instead. This provides a way of altering the behaviour of func-
tions that can perform many different completions. It is imple-
mented by setting the parameter $service when calling the func-
tion; the function may choose to interpret this how it wishes,
and simpler functions will probably ignore it.
If the #compdef line contains one of the options -p or -P, the
words following are taken to be patterns. The function will be
called when completion is attempted for a command or context
that matches one of the patterns. The options -p and -P are
used to specify patterns to be tried before or after other com-
pletions respectively. Hence -P may be used to specify default
actions.
The option -N is used after a list following -p or -P; it speci-
fies that remaining words no longer define patterns. It is pos-
sible to toggle between the three options as many times as nec-
essary.
#compdef -k style key-sequences...
This option creates a widget behaving like the builtin widget
style and binds it to the given key-sequences, if any. The
style must be one of the builtin widgets that perform comple-
tion, namely complete-word, delete-char-or-list, expand-or-com-
plete, expand-or-complete-prefix, list-choices, menu-complete,
menu-expand-or-complete, or reverse-menu-complete. If the
zsh/complist module is loaded (see zshmodules(1)) the widget
menu-select is also available.
When one of the key-sequences is typed, the function in the file
will be invoked to generate the matches. Note that a key will
not be re-bound if if it already was (that is, was bound to
something other than undefined-key). The widget created has the
same name as the file and can be bound to any other keys using
bindkey as usual.
#compdef -K widget-name style key-sequences ...
This is similar to -k except that only one key-sequences argu-
ment may be given for each widget-name style pair. However, the
entire set of three arguments may be repeated with a different
set of arguments. Note in particular that the widget-name must
be distinct in each set. If it does not begin with ‘_’ this
will be added. The widget-name should not clash with the name
of any existing widget: names based on the name of the function
are most useful. For example,
#compdef -K _foo_complete complete-word "^X^C" \
_foo_list list-choices "^X^D"
(all on one line) defines a widget _foo_complete for completion,
bound to ‘^X^C’, and a widget _foo_list for listing, bound to
‘^X^D’.
#autoload [ options ]
Functions with the #autoload tag are marked for autoloading but
are not otherwise treated specially. Typically they are to be
called from within one of the completion functions. Any options
supplied will be passed to the autoload builtin; a typical use
is +X to force the function to be loaded immediately. Note that
the -U and -z flags are always added implicitly.
The # is part of the tag name and no white space is allowed after it.
The #compdef tags use the compdef function described below; the main
difference is that the name of the function is supplied implicitly.
The special contexts for which completion functions can be defined are:
-array-value-
The right hand side of an array-assignment (‘foo=(...)’)
-brace-parameter-
The name of a parameter expansion within braces (‘${...}’)
-assign-parameter-
The name of a parameter in an assignment, i.e. on the left hand
side of an ‘=’
-command-
A word in command position
-condition-
A word inside a condition (‘[[...]]’)
-default-
Any word for which no other completion is defined
-equal-
A word beginning with an equals sign
-first-
This is tried before any other completion function. The func-
tion called may set the _compskip parameter to one of various
values: all: no further completion is attempted; a string con-
taining the substring patterns: no pattern completion functions
will be called; a string containing default: the function for
the ‘-default-’ context will not be called, but functions
defined for commands will
-math- Inside mathematical contexts, such as ‘((...))’
-parameter-
The name of a parameter expansion (‘$...’)
-redirect-
The word after a redirection operator.
-subscript-
The contents of a parameter subscript.
-tilde-
After an initial tilde (‘~’), but before the first slash in the
word.
-value-
On the right hand side of an assignment.
Default implementations are supplied for each of these contexts. In
most cases the context -context- is implemented by a corresponding
function _context, for example the context ‘-tilde-’ and the function
‘_tilde’).
The contexts -redirect- and -value- allow extra context-specific infor-
mation. (Internally, this is handled by the functions for each context
calling the function _dispatch.) The extra information is added sepa-
rated by commas.
For the -redirect- context, the extra information is in the form
‘-redirect-,op,command’, where op is the redirection operator and com-
mand is the name of the command on the line. If there is no command on
the line yet, the command field will be empty.
For the -value- context, the form is ‘-value-,name,command’, where name
is the name of the parameter. In the case of elements of an associa-
tive array, for example ‘assoc=(key <TAB>’, name is expanded to
‘name-key’. In certain special contexts, such as completing after
‘make CFLAGS=’, the command part gives the name of the command, here
make; otherwise it is empty.
It is not necessary to define fully specific completions as the func-
tions provided will try to generate completions by progressively
replacing the elements with ‘-default-’. For example, when completing
after ‘foo=<TAB>’, _value will try the names ‘-value-,foo,’ (note the
empty command part), ‘-value-,foo,-default-’
and‘-value-,-default-,-default-’, in that order, until it finds a func-
tion to handle the context.
As an example:
compdef â€â€™_files -g "*.log"â€â€™ â€â€™-redirect-,2>,-default-â€â€™
completes files matching ‘*.log’ after ‘2> <TAB>’ for any command with
no more specific handler defined.
Also:
compdef _foo -value-,-default-,-default-
specifies that _foo provides completions for the values of parameters
for which no special function has been defined. This is usually han-
dled by the function _value itself.
The same lookup rules are used when looking up styles (as described
below); for example
zstyle â€â€™:completion:*:*:-redirect-,2>,*:*â€â€™ file-patterns â€â€™*.logâ€â€™
is another way to make completion after ‘2> <TAB>’ complete files
matching ‘*.log’.
Functions
The following function is defined by compinit and may be called
directly.
compdef [ -an ] function names... [ -[pP] patterns... [ -N names... ] ]
compdef -d names...
compdef -k [ -an ] function style key-sequences...
compdef -K [ -an ] function name style key-sequences ...
The first form defines the function to call for completion in
the given contexts as described for the #compdef tag above.
Alternatively, all the arguments may have the form ‘cmd=ser-
vice’. Here service should already have been defined by
‘cmd1=service’ lines in #compdef files, as described above. The
argument for cmd will be completed in the same way as service.
The function argument may alternatively be a string containing
any shell code. The string will be executed using the eval
builtin command to generate completions. This provides a way of
avoiding having to define a new completion function. For exam-
ple, to complete files ending in ‘.h’ as arguments to the com-
mand foo:
compdef â€â€™_files -g "*.h"â€â€™ foo
The option -n prevents any completions already defined for the
command or context from being overwritten.
The option -d deletes any completion defined for the command or
contexts listed.
The names may also contain -p, -P and -N options as described
for the #compdef tag. The effect on the argument list is iden-
tical, switching between definitions of patterns tried ini-
tially, patterns tried finally, and normal commands and con-
texts.
The parameter $_compskip may be set by any function defined for
a pattern context. If it is set to a value containing the sub-
string ‘patterns’ none of the pattern-functions will be called;
if it is set to a value containing the substring ‘all’, no other
function will be called.
The form with -k defines a widget with the same name as the
function that will be called for each of the key-sequences; this
is like the #compdef -k tag. The function should generate the
completions needed and will otherwise behave like the builtin
widget whose name is given as the style argument. The widgets
usable for this are: complete-word, delete-char-or-list,
expand-or-complete, expand-or-complete-prefix, list-choices,
menu-complete, menu-expand-or-complete, and reverse-menu-com-
plete, as well as menu-select if the zsh/complist module is
loaded. The option -n prevents the key being bound if it is
already to bound to something other than undefined-key.
The form with -K is similar and defines multiple widgets based
on the same function, each of which requires the set of three
arguments name, style and key-sequences, where the latter two
are as for -k and the first must be a unique widget name begin-
ning with an underscore.
Wherever applicable, the -a option makes the function autoload-
able, equivalent to autoload -U function.
The function compdef can be used to associate existing completion func-
tions with new commands. For example,
compdef _pids foo
uses the function _pids to complete process IDs for the command foo.
Note also the _gnu_generic function described below, which can be used
to complete options for commands that understand the ‘--help’ option.
COMPLETION SYSTEM CONFIGURATION
This section gives a short overview of how the completion system works,
and then more detail on how users can configure how and when matches
are generated.
Overview
When completion is attempted somewhere on the command line the comple-
tion system first works out the context. This takes account of a num-
ber of things including the command word (such as ‘grep’ or ‘zsh’) and
options to which the current word may be an argument (such as the ‘-o’
option to zsh which takes a shell option as an argument).
This context information is condensed into a string consisting of mul-
tiple fields separated by colons, referred to simply as ‘the context’
in the remainder of the documentation. This is used to look up styles,
context-sensitive options that can be used to configure the completion
system. The context used for lookup may vary during the same call to
the completion system.
The context string always consists of the following fields, separated
by colons and with a leading colon before the first:
· The literal string completion, saying that this style is used by
the completion system. This distinguishes the context from
those used by, for example, zle widgets and ZFTP functions.
· The function, if completion is called from a named widget rather
than through the normal completion system. Typically this is
blank, but it is set by special widgets such as predict-on and
the various functions in the Widget directory of the distribu-
tion to the name of that function, often in an abbreviated form.
· The completer currently active, the name of the function without
the leading underscore. A ‘completer’ is in overall control of
how completion is to be performed; ‘complete’ is the simplest,
but other completers exist to perform related tasks such as cor-
rection, or to modify the behaviour of a later completer. See
the section ‘Control Functions’ below for more information.
· The command or a special -context-, just at it appears following
the #compdef tag or the compdef function. Completion functions
for commands that have sub-commands usually modify this field to
contain the name of the command followed by a minus sign and the
sub-command. For example, the completion function for the cvs
command sets this field to cvs-add when completing arguments to
the add subcommand.
· The argument; this indicates which command line or option argu-
ment we are completing. For command arguments this generally
takes the form argument-n, where n is the number of the argu-
ment, and for arguments to options the form option-opt-n where n
is the number of the argument to option opt. However, this is
only the case if the command line is parsed with standard
UNIX-style options and arguments, so many completions do not set
this.
· The tag. Tags are used to discriminate between the types of
matches a completion function can generate in a certain context
and are described further below.
As an example, the context name
:completion::complete:dvips:option-o-1:files
says that normal completion was attempted as the first argument to the
option -o of the command dvips:
dvips -o ...
and the completion function will generate filenames.
Each type of completion the system can perform in a given context is
described by a ‘tag’, a short descriptive string such as files in the
example above. Any completion function may use any tag name it likes,
but a list of the more common ones is given below.
Usually completion will be tried by all possible tags in an order given
by the completion function. However, this can be altered by using the
tag-order style. Completion is then restricted to the list of given
tags in the given order.
The _complete_help bindable command shows all the contexts and tags
available for completion at a particular point. This provides an easy
way of finding information for tag-order and other styles. It is
described in the section ‘Bindable Commands’ below.
Styles determine such things as how the matches are generated, simi-
larly to shell options but with much more control. They can have any
number of strings as their value. They are defined with the zstyle
builtin command (see zshmodules(1)).
When looking up styles the completion system uses full context names,
including the tag. Looking up the value of a style therefore consists
of two things: the context, which may be matched as a pattern, and the
name of the style itself, which must be given exactly.
For example, many completion functions can generate matches in a simple
and a verbose form and use the verbose style to decide which form
should be used. To make all such functions use the verbose form, put
zstyle â€â€™:completion:*â€â€™ verbose yes
in a startup file (probably .zshrc). This gives the verbose style the
value yes in every context inside the completion system, unless that
context has a more specific definition. It is best to avoid giving the
context as ‘*’ in case the style has some meaning outside the comple-
tion system.
Many such general purpose styles can be configured simply by using the
compinstall function.
A more specific example of the use of the verbose style is by the com-
pletion for the kill builtin. If the style is set, the builtin lists
full job texts and process command lines; otherwise it shows the bare
job numbers and PIDs. To turn the style off for this use only:
zstyle â€â€™:completion:*:*:kill:*â€â€™ verbose no
For even more control, the style can use one of the tags ‘jobs’ or
‘processes’. To turn off verbose display only for jobs:
zstyle â€â€™:completion:*:*:kill:*:jobsâ€â€™ verbose no
The -e option to zstyle even allows completion function code to appear
as the argument to a style; this requires some understanding of the
internals of completion functions (see see zshcompwid(1))). For exam-
ple:
zstyle -e â€â€™:completion:*â€â€™ completer â€â€™
if [[ $words[1] = cvs ]]; then
reply=(_complete)
else
reply=(_complete _approximate)
fiâ€â€™
uses the value ‘_complete’ for the completer style in most contexts,
but the value ‘_complete _approximate’ when the first word on the com-
mand line is ‘cvs’. This is probably more conveniently done by speci-
fying the style for two different contexts. This form can be slow and
should be avoided for commonly examined styles such as menu and
list-rows-first.
Note that the order in which styles are defined does not matter; the
style mechanism uses the most specific possible match for a particular
style to determine the set of values. More precisely, strings are pre-
ferred over patterns (for example, ‘:completion::complete:foo’ is more
specific than ‘:completion::complete:*â€â€™), and longer patterns are pre-
ferred over shorter patterns.
Style names like those of tags are arbitrary and depend on the comple-
tion function. However, the following two sections list some of the
most common tags and styles.
Standard Tags
Some of the following are only used when looking up particular styles
and do not refer to a type of match.
accounts
used to look up the users-hosts style
all-expansions
used by the _expand completer when adding the single string con-
taining all possible expansions
all-files
for the names of all files (as distinct from a particular sub-
set, see the globbed-files tag).
arguments
for arguments to a command
arrays for names of array parameters
association-keys
for keys of associative arrays; used when completing inside a
subscript to a parameter of this type
bookmarks
when completing bookmarks (e.g. for URLs and the zftp function
suite)
builtins
for names of builtin commands
characters
for single characters in arguments of commands such as stty.
Also used when completing character classes after an opening
bracket
colormapids
for X colormap ids
colors for color names
commands
for names of external commands. Also used by complex commands
such as cvs when completing names subcommands.
contexts
for contexts in arguments to the zstyle builtin command
corrections
used by the _approximate and _correct completers for possible
corrections
cursors
for cursor names used by X programs
default
used in some contexts to provide a way of supplying a default
when more specific tags are also valid. Note that this tag is
used when only the function field of the context name is set
descriptions
used when looking up the value of the format style to generate
descriptions for types of matches
devices
for names of device special files
directories
for names of directories
directory-stack
for entries in the directory stack
displays
for X display names
domains
for network domains
expansions
used by the _expand completer for individual words (as opposed
to the complete set of expansions) resulting from the expansion
of a word on the command line
extensions
for X server extensions
file-descriptors
for numbers of open file descriptors
files the generic file-matching tag used by functions completing file-
names
fonts for X font names
fstypes
for file system types (e.g. for the mount command)
functions
names of functions --- normally shell functions, although cer-
tain commands may understand other kinds of function
globbed-files
for filenames when the name has been generated by pattern match-
ing
groups for names of user groups
history-words
for words from the history
hosts for hostnames
indexes
for array indexes
jobs for jobs (as listed by the ‘jobs’ builtin)
interfaces
for network interfaces
keymaps
for names of zsh keymaps
keysyms
for names of X keysyms
libraries
for names of system libraries
limits for system limits
local-directories
for names of directories that are subdirectories of the current
working directory when completing arguments of cd and related
builtin commands (compare path-directories)
manuals
for names of manual pages
mailboxes
for e-mail folders
maps for map names (e.g. NIS maps)
messages
used to look up the format style for messages
modifiers
for names of X modifiers
modules
for modules (e.g. zsh modules)
my-accounts
used to look up the users-hosts style
named-directories
for named directories (you wouldn’t have guessed that, would
you?)
names for all kinds of names
newsgroups
for USENET groups
nicknames
for nicknames of NIS maps
options
for command options
original
used by the _approximate, _correct and _expand completers when
offering the original string as a match
other-accounts
used to look up the users-hosts style
packages
for packages (e.g. rpm or installed Debian packages)
parameters
for names of parameters
path-directories
for names of directories found by searching the cdpath array
when completing arguments of cd and related builtin commands
(compare local-directories)
paths used to look up the values of the expand, ambiguous and spe-
cial-dirs styles
pods for perl pods (documentation files)
ports for communication ports
prefixes
for prefixes (like those of a URL)
printers
for print queue names
processes
for process identifiers
processes-names
used to look up the command style when generating the names of
processes for killall
sequences
for sequences (e.g. mh sequences)
sessions
for sessions in the zftp function suite
signals
for signal names
strings
for strings (e.g. the replacement strings for the cd builtin
command)
styles for styles used by the zstyle builtin command
suffixes
for filename extensions
tags for tags (e.g. rpm tags)
targets
for makefile targets
time-zones
for time zones (e.g. when setting the TZ parameter)
types for types of whatever (e.g. address types for the xhost command)
urls used to look up the urls and local styles when completing URLs
users for usernames
values for one of a set of values in certain lists
variant
used by _pick_variant to look up the command to run when deter-
mining what program is installed for a particular command name.
visuals
for X visuals
warnings
used to look up the format style for warnings
widgets
for zsh widget names
windows
for IDs of X windows
zsh-options
for shell options
Standard Styles
Note that the values of several of these styles represent boolean val-
ues. Any of the strings ‘true’, ‘on’, ‘yes’, and ‘1’ can be used for
the value ‘true’ and any of the strings ‘false’, ‘off’, ‘no’, and ‘0’
for the value ‘false’. The behavior for any other value is undefined
except where explicitly mentioned. The default value may be either
true or false if the style is not set.
Some of these styles are tested first for every possible tag corre-
sponding to a type of match, and if no style was found, for the default
tag. The most notable styles of this type are menu, list-colors and
styles controlling completion listing such as list-packed and
last-prompt). When tested for the default tag, only the function field
of the context will be set so that a style using the default tag will
normally be defined along the lines of:
zstyle â€â€™:completion:*:defaultâ€â€™ menu ...
accept-exact
This is tested for the default tag in addition to the tags valid
for the current context. If it is set to ‘true’ and any of the
trial matches is the same as the string on the command line,
this match will immediately be accepted (even if it would other-
wise be considered ambiguous).
When completing pathnames (where the tag used is ‘paths’) this
style accepts any number of patterns as the value in addition to
the boolean values. Pathnames matching one of these patterns
will be accepted immediately even if the command line contains
some more partially typed pathname components and these match no
file under the directory accepted.
This style is also used by the _expand completer to decide if
words beginning with a tilde or parameter expansion should be
expanded. For example, if there are parameters foo and foobar,
the string ‘$foo’ will only be expanded if accept-exact is set
to ‘true’; otherwise the completion system will be allowed to
complete $foo to $foobar. If the style is set to ‘continue’,
_expand will add the expansion as a match and the completion
system will also be allowed to continue.
add-space
This style is used by the _expand completer. If it is true (the
default), a space will be inserted after all words resulting
from the expansion, or a slash in the case of directory names.
If the value is ‘file’, the completer will only add a space to
names of existing files. Either a boolean true or the value
‘file’ may be combined with ‘subst’, in which case the completer
will not add a space to words generated from the expansion of a
substitution of the form ‘$(...)’ or ‘${...}’.
The _prefix completer uses this style as a simple boolean value
to decide if a space should be inserted before the suffix.
ambiguous
This applies when completing non-final components of filename
paths, in other words those with a trailing slash. If it is
set, the cursor is left after the first ambiguous component,
even if menu completion is in use. The style is always tested
with the paths tag.
assign-list
When completing after an equals sign that is being treated as an
assignment, the completion system normally completes only one
filename. In some cases the value may be a list of filenames
separated by colons, as with PATH and similar parameters. This
style can be set to a list of patterns matching the names of
such parameters.
The default is to complete lists when the word on the line
already contains a colon.
auto-description
If set, this style’s value will be used as the description for
options that are not described by the completion functions, but
that have exactly one argument. The sequence ‘%d’ in the value
will be replaced by the description for this argument. Depend-
ing on personal preferences, it may be useful to set this style
to something like ‘specify: %d’. Note that this may not work
for some commands.
avoid-completer
This is used by the _all_matches completer to decide if the
string consisting of all matches should be added to the list
currently being generated. Its value is a list of names of com-
pleters. If any of these is the name of the completer that gen-
erated the matches in this completion, the string will not be
added.
The default value for this style is ‘_expand _old_list _correct
_approximate’, i.e. it contains the completers for which a
string with all matches will almost never be wanted.
cache-path
This style defines the path where any cache files containing
dumped completion data are stored. It defaults to ‘$ZDOT-
DIR/.zcompcache’, or ‘$HOME/.zcompcache’ if $ZDOTDIR is not
defined. The completion cache will not be used unless the
use-cache style is set.
cache-policy
This style defines the function that will be used to determine
whether a cache needs rebuilding. See the section on the
_cache_invalid function below.
call-command
This style is used in the function for commands such as make and
ant where calling the command directly to generate matches suf-
fers problems such as being slow or, as in the case of make can
potentially causes actions in the makefile to be executed. If it
is set to ‘true’ the command is called to generate matches. The
default value of this style is ‘false’.
command
In many places, completion functions need to call external com-
mands to generate the list of completions. This style can be
used to override the command that is called in some such cases.
The elements of the value are joined with spaces to form a com-
mand line to execute. The value can also start with a hyphen,
in which case the usual command will be added to the end; this
is most useful for putting ‘builtin’ or ‘command’ in front to
make sure the appropriate version of a command is called, for
example to avoid calling a shell function with the same name as
an external command.
As an example, the completion function for process IDs uses this
style with the processes tag to generate the IDs to complete and
the list of processes to display (if the verbose style is
‘true’). The list produced by the command should look like the
output of the ps command. The first line is not displayed, but
is searched for the string ‘PID’ (or ‘pid’) to find the position
of the process IDs in the following lines. If the line does not
contain ‘PID’, the first numbers in each of the other lines are
taken as the process IDs to complete.
Note that the completion function generally has to call the
specified command for each attempt to generate the completion
list. Hence care should be taken to specify only commands that
take a short time to run, and in particular to avoid any that
may never terminate.
command-path
This is a list of directories to search for commands to com-
plete. The default for this style is the value of the special
parameter path.
commands
This is used by the function completing sub-commands for the
system initialisation scripts (residing in /etc/init.d or some-
where not too far away from that). Its values give the default
commands to complete for those commands for which the completion
function isn’t able to find them out automatically. The default
for this style are the two strings ‘start’ and ‘stop’.
complete
This is used by the _expand_alias function when invoked as a
bindable command. If it set to ‘true’ and the word on the com-
mand line is not the name of an alias, matching alias names will
be completed.
completer
The strings given as the value of this style provide the names
of the completer functions to use. The available completer func-
tions are described in the section ‘Control Functions’ below.
Each string may be either the name of a completer function or a
string of the form ‘function:name’. In the first case the com-
pleter field of the context will contain the name of the com-
pleter without the leading underscore and with all other under-
scores replaced by hyphens. In the second case the function is
the name of the completer to call, but the context will contain
the user-defined name in the completer field of the context. If
the name starts with a hyphen, the string for the context will
be build from the name of the completer function as in the first
case with the name appended to it. For example:
zstyle â€â€™:completion:*â€â€™ completer _complete _complete:-foo
Here, completion will call the _complete completer twice, once
using ‘complete’ and once using ‘complete-foo’ in the completer
field of the context. Normally, using the same completer more
than once only makes sense when used with the ‘functions:name’
form, because otherwise the context name will be the same in all
calls to the completer; possible exceptions to this rule are the
_ignored and _prefix completers.
The default value for this style is ‘_complete _ignored’: only
completion will be done, first using the ignored-patterns style
and the $fignore array and then without ignoring matches.
condition
This style is used by the _list completer function to decide if
insertion of matches should be delayed unconditionally. The
default is ‘true’.
disabled
If this is set to ‘true’, the _expand_alias completer and bind-
able command will try to expand disabled aliases, too. The
default is ‘false’.
disable-stat
This is used with an empty tag by the _cvs function to decide
whether the zsh/stat module should be used to generate names of
modified files in the appropriate places (this is its only use).
If the style is set, completion will use the ls command.
domains
A list of names of network domains for completion. If this is
not set, domain names will be taken from the file
/etc/resolv.conf.
expand This style is used when completing strings consisting of multi-
ple parts, such as path names.
If one of its values is the string ‘prefix’, the partially typed
word from the line will be expanded as far as possible even if
trailing parts cannot be completed.
If one of its values is the string ‘suffix’, matching names for
components after the first ambiguous one will also be added.
This means that the resulting string is the longest unambiguous
string possible. However, menu completion can be used to cycle
through all matches.
fake This style may be set for any completion context. It specifies
additional strings that will always be completed in that con-
text. The form of each string is ‘value:description’; the colon
and description may be omitted, but any literal colons in value
must be quoted with a backslash. Any description provided is
shown alongside the value in completion listings.
It is important to use a sufficiently restrictive context when
specifying fake strings. Note that the styles fake-files and
fake-parameters provide additional features when completing
files or parameters.
fake-files
This style is used when completing files and looked up without a
tag. Its values are of the form ‘dir:names...’. This will add
the names (strings separated by spaces) as possible matches when
completing in the directory dir, even if no such files really
exist.
This can be useful on systems that support special filesystems
whose top-level pathnames can not be listed or generated with
glob patterns. It can also be used for directories for which
one does not have read permission.
fake-parameters
This is used by the completion function for parameter names.
Its values are names of parameters that might not yet be set but
should be completed nonetheless. Each name may also be followed
by a colon and a string specifying the type of the parameter
(like ‘scalar’, ‘array’ or ‘integer’). If the type is given,
the name will only be completed if parameters of that type are
required in the particular context. Names for which no type is
specified will always be completed.
file-patterns
This is used by the standard function for completing filenames,
_files. If the style is unset up to three tags are offered,
‘globbed-files’,‘directories’ and ‘all-files’, depending on the
types of files expected by the caller of _files. The first two
(‘globbed-files’ and ‘directories’) are normally offered
together to make it easier to complete files in sub-directories.
The file-patterns style provides alternatives to the default
tags, which are not used. Its value consists of elements of the
form ‘pattern:tag’; each string may contain any number of such
specifications separated by spaces.
The pattern is a pattern that is to be used to generate file-
names. Any occurrence of the sequence ‘%p’ is replaced by any
pattern(s) passed by the function calling _files. Colons in the
pattern must be preceded by a backslash to make them distin-
guishable from the colon before the tag. If more than one pat-
tern is needed, the patterns can be given inside braces, sepa-
rated by commas.
The tags of all strings in the value will be offered by _files
and used when looking up other styles. Any tags in the same
word will be offered at the same time and before later words.
If no ‘:tag’ is given the ‘files’ tag will be used.
The tag may also be followed by an optional second colon and a
description, which will be used for the ‘%d’ in the value of the
format style (if that is set) instead of the default description
supplied by the completion function. If the description given
here contains itself a ‘%d’, that is replaced with the descrip-
tion supplied by the completion function.
For example, to make the rm command first complete only names of
object files and then the names of all files if there is no
matching object file:
zstyle â€â€™:completion:*:*:rm:*â€â€™ file-patterns \
â€â€™*.o:object-filesâ€â€™ â€â€™%p:all-filesâ€â€™
To alter the default behaviour of file completion --- offer
files matching a pattern and directories on the first attempt,
then all files --- to offer only matching files on the first
attempt, then directories, and finally all files:
zstyle â€â€™:completion:*â€â€™ file-patterns \
â€â€™%p:globbed-filesâ€â€™ â€â€™*(-/):directoriesâ€â€™ â€â€™*:all-filesâ€â€™
This works even where there is no special pattern: _files
matches all files using the pattern ‘*’ at the first step and
stops when it sees this pattern. Note also it will never try a
pattern more than once for a single completion attempt.
During the execution of completion functions, the EXTENDED_GLOB
option is in effect, so the characters ‘#’, ‘~’ and ‘^’ have
special meanings in the patterns.
file-sort
The standard filename completion function uses this style with-
out a tag to determine in which order the names should be
listed; menu completion will cycle through them in the same
order. The possible values are: ‘size’ to sort by the size of
the file; ‘links’ to sort by the number of links to the file;
‘modification’ (or ‘time’ or ‘date’) to sort by the last modifi-
cation time; ‘access’ to sort by the last access time; and
‘inode’ (or ‘change’) to sort by the last inode change time. If
the style is set to any other value, or is unset, files will be
sorted alphabetically by name. If the value contains the string
‘reverse’, sorting is done in the opposite order.
filter This is used by the LDAP plugin for e-mail address completion to
specify the attributes to match against when filtering entries.
So for example, if the style is set to ‘sn’, matching is done
against surnames. Standard LDAP filtering is used so normal
completion matching is bypassed. If this style is not set, the
LDAP plugin is skipped. You may also need to set the command
style to specify how to connect to your LDAP server.
force-list
This forces a list of completions to be shown at any point where
listing is done, even in cases where the list would usually be
suppressed. For example, normally the list is only shown if
there are at least two different matches. By setting this style
to ‘always’, the list will always be shown, even if there is
only a single match that will immediately be accepted. The
style may also be set to a number. In this case the list will
be shown if there are at least that many matches, even if they
would all insert the same string.
This style is tested for the default tag as well as for each tag
valid for the current completion. Hence the listing can be
forced only for certain types of match.
format If this is set for the descriptions tag, its value is used as a
string to display above matches in completion lists. The
sequence ‘%d’ in this string will be replaced with a short
description of what these matches are. This string may also
contain the sequences to specify output attributes, such as
‘%B’, ‘%S’ and ‘%{...%}’.
The style is tested with each tag valid for the current
completion before it is tested for the descriptions tag. Hence
different format strings can be defined for different types of
match.
Note also that some completer functions define additional
‘%’-sequences. These are described for the completer functions
that make use of them.
Some completion functions display messages that may be cus-
tomised by setting this style for the messages tag. Here, the
‘%d’ is replaced with a message given by the completion func-
tion.
Finally, the format string is looked up with the warnings tag,
for use when no matches could be generated at all. In this case
the ‘%d’ is replaced with the descriptions for the matches that
were expected separated by spaces. The sequence ‘%D’ is
replaced with the same descriptions separated by newlines.
It is possible to use printf-style field width specifiers with
‘%d’ and similar escape sequences. This is handled by the zfor-
mat builtin command from the zsh/zutil module, see zshmod-
ules(1).
glob This is used by the _expand completer. If it is set to ‘true’
(the default), globbing will be attempted on the words resulting
from a previous substitution (see the substitute style) or else
the original string from the line.
global If this is set to ‘true’ (the default), the _expand_alias com-
pleter and bindable command will try to expand global aliases.
group-name
The completion system can group different types of matches,
which appear in separate lists. This style can be used to give
the names of groups for particular tags. For example, in com-
mand position the completion system generates names of builtin
and external commands, names of aliases, shell functions and
parameters and reserved words as possible completions. To have
the external commands and shell functions listed separately:
zstyle â€â€™:completion:*:*:-command-:*:commandsâ€â€™ group-name commands
zstyle â€â€™:completion:*:*:-command-:*:functionsâ€â€™ group-name functions
As a consequence, any match with the same tag will be displayed
in the same group.
If the name given is the empty string the name of the tag for
the matches will be used as the name of the group. So, to have
all different types of matches displayed separately, one can
just set:
zstyle â€â€™:completion:*â€â€™ group-name â€â€™â€â€™
All matches for which no group name is defined will be put in a
group named -default-.
group-order
This style is additional to the group-name style to specify the
order for display of the groups defined by that style (compare
tag-order, which determines which completions appear at all).
The groups named are shown in the given order; any other groups
are shown in the order defined by the completion function.
For example, to have names of builtin commands, shell functions
and external commands appear in that order when completing in
command position:
zstyle â€â€™:completion:*:*:-command-:*â€â€™ group-order \
builtins functions commands
groups A list of names of UNIX groups. If this is not set, group names
are taken from the YP database or the file ‘/etc/group’.
hidden If this is set to true, matches for the given context will not
be listed, although any description for the matches set with the
format style will be shown. If it is set to ‘all’, not even the
description will be displayed.
Note that the matches will still be completed; they are just not
shown in the list. To avoid having matches considered as possi-
ble completions at all, the tag-order style can be modified as
described below.
hosts A list of names of hosts that should be completed. If this is
not set, hostnames are taken from the file ‘/etc/hosts’.
hosts-ports
This style is used by commands that need or accept hostnames and
network ports. The strings in the value should be of the form
‘host:port’. Valid ports are determined by the presence of
hostnames; multiple ports for the same host may appear.
ignore-line
This is tested for each tag valid for the current completion.
If it is set to ‘true’, none of the words that are already on
the line will be considered as possible completions. If it is
set to ‘current’, the word the cursor is on will not be consid-
ered as a possible completion. The value ‘current-shown’ is
similar but only applies if the list of completions is currently
shown on the screen. Finally, if the style is set to ‘other’,
no word apart from the current one will be considered as a pos-
sible completion.
The values ‘current’ and ‘current-shown’ are a bit like the
opposite of the accept-exact style: only strings with missing
characters will be completed.
Note that you almost certainly don’t want to set this to ‘true’
or ‘other’ for a general context such as ‘:completion:*’. This
is because it would disallow completion of, for example, options
multiple times even if the command in question accepts the
option more than once.
ignore-parents
The style is tested without a tag by the function completing
pathnames in order to determine whether to ignore the names of
directories already mentioned in the current word, or the name
of the current working directory. The value must include one or
both of the following strings:
parent The name of any directory whose path is already contained
in the word on the line is ignored. For example, when
completing after foo/../, the directory foo will not be
considered a valid completion.
pwd The name of the current working directory will not be
completed; hence, for example, completion after ../ will
not use the name of the current directory.
In addition, the value may include one or both of:
.. Ignore the specified directories only when the word on
the line contains the substring ‘../’.
directory
Ignore the specified directories only when names of
directories are completed, not when completing names of
files.
Excluded values act in a similar fashion to values of the
ignored-patterns style, so they can be restored to consideration
by the _ignored completer.
ignored-patterns
A list of patterns; any trial completion matching one of the
patterns will be excluded from consideration. The _ignored
completer can appear in the list of completers to restore the
ignored matches. This is a more configurable version of the
shell parameter $fignore.
Note that the EXTENDED_GLOB option is set during the execution
of completion functions, so the characters ‘#’, ‘~’ and ‘^’ have
special meanings in the patterns.
insert This style is used by the _all_matches completer to decide
whether to insert the list of all matches unconditionally
instead of adding the list as another match.
insert-ids
When completing process IDs, for example as arguments to the
kill and wait builtins the name of a command may be converted to
the appropriate process ID. A problem arises when the process
name typed is not unique. By default (or if this style is set
explicitly to ‘menu’) the name will be converted immediately to
a set of possible IDs, and menu completion will be started to
cycle through them.
If the value of the style is ‘single’, the shell will wait until
the user has typed enough to make the command unique before con-
verting the name to an ID; attempts at completion will be unsuc-
cessful until that point. If the value is any other string,
menu completion will be started when the string typed by the
user is longer than the common prefix to the corresponding IDs.
insert-tab
If this is set to ‘true’, the completion system will insert a
TAB character (assuming that was used to start completion)
instead of performing completion when there is no non-blank
character to the left of the cursor. If it is set to ‘false’,
completion will be done even there.
The value may also contain the substrings ‘pending’ or ‘pend-
ing=val’. In this case, the typed character will be inserted
instead of staring completion when there is unprocessed input
pending. If a val is given, completion will not be done if
there are at least that many characters of unprocessed input.
This is often useful when pasting characters into a terminal.
Note however, that it relies on the $PENDING special parameter
from the zsh/zle module being set properly which is not guaran-
teed on all platforms.
The default value of this style is ‘true’ except for completion
within vared builtin command where it is ‘false’.
insert-unambiguous
This is used by the _match and _approximate completers. These
completers are often used with menu completion since the word
typed may bear little resemblance to the final completion. How-
ever, if this style is ‘true’, the completer will start menu
completion only if it could find no unambiguous initial string
at least as long as the original string typed by the user.
In the case of the _approximate completer, the completer field
in the context will already have been set to one of correct-num
or approximate-num, where num is the number of errors that were
accepted.
In the case of the _match completer, the style may also be set
to the string ‘pattern’. Then the pattern on the line is left
unchanged if it does not match unambiguously.
keep-prefix
This style is used by the _expand completer. If it is ‘true’,
the completer will try to keep a prefix containing a tilde or
parameter expansion. Hence, for example, the string ‘~/f*’
would be expanded to ‘~/foo’ instead of ‘/home/user/foo’. If
the style is set to ‘changed’ (the default), the prefix will
only be left unchanged if there were other changes between the
expanded words and the original word from the command line. Any
other value forces the prefix to be expanded unconditionally.
The behaviour of expand when this style is true is to cause
_expand to give up when a single expansion with the restored
prefix is the same as the original; hence any remaining com-
pleters may be called.
last-prompt
This is a more flexible form of the ALWAYS_LAST_PROMPT option.
If it is true, the completion system will try to return the cur-
sor to the previous command line after displaying a completion
list. It is tested for all tags valid for the current comple-
tion, then the default tag. The cursor will be moved back to
the previous line if this style is ‘true’ for all types of
match. Note that unlike the ALWAYS_LAST_PROMPT option this is
independent of the numeric prefix argument.
list This style is used by the _history_complete_word bindable com-
mand. If it is set to ‘true’ it has no effect. If it is set to
‘false’ matches will not be listed. This overrides the setting
of the options controlling listing behaviour, in particular
AUTO_LIST. The context always starts with ‘:completion:his-
tory-words’.
list-colors
If the zsh/complist module is loaded, this style can be used to
set color specifications. This mechanism replaces the use of
the ZLS_COLORS and ZLS_COLOURS parameters described in the sec-
tion ‘The zsh/complist Module’ in zshmodules(1), but the syntax
is the same.
If this style is set for the default tag, the strings in the
value are taken as specifications that are to be used every-
where. If it is set for other tags, the specifications are used
only for matches of the type described by the tag. For this to
work best, the group-name style must be set to an empty string.
In addition to setting styles for specific tags, it is also pos-
sible to use group names specified explicitly by the group-name
tag together with the ‘(group)’ syntax allowed by the ZLS_COLORS
and ZLS_COLOURS parameters and simply using the default tag.
It is possible to use any color specifications already set up
for the GNU version of the ls command:
zstyle â€â€™:completion:*:defaultâ€â€™ list-colors ${(s.:.)LS_COLORS}
The default colors are the same as for the GNU ls command and
can be obtained by setting the style to an empty string (i.e.
â€â€™â€â€™).
list-grouped
If this style is ‘true’ (the default), the completion system
will try to make certain completion listings more compact by
grouping matches. For example, options for commands that have
the same description (shown when the verbose style is set to
‘true’) will appear as a single entry. However, menu selection
can be used to cycle through all the matches.
list-packed
This is tested for each tag valid in the current context as well
as the default tag. If it is set to ‘true’, the corresponding
matches appear in listings as if the LIST_PACKED option were
set. If it is set to ‘false’, they are listed normally.
list-prompt
If this style is set for the default tag, completion lists that
don’t fit on the screen can be scrolled (see the description of
the zsh/complist module in zshmodules(1)). The value, if not
the empty string, will be displayed after every screenful and
the shell will prompt for a key press; if the style is set to
the empty string, a default prompt will be used.
The value may contain the escape sequences: ‘%l’ or ‘%L’, which
will be replaced by the number of the last line displayed and
the total number of lines; ‘%m’ or ‘%M’, the number of the last
match shown and the total number of matches; and ‘%p’ and ‘%P’,
‘Top’ when at the beginning of the list, ‘Bottom’ when at the
end and the position shown as a percentage of the total length
otherwise. In each case the form with the uppercase letter will
be replaced by a string of fixed width, padded to the right
with spaces, while the lowercase form will be replaced by a
variable width string. As in other prompt strings, the escape
sequences ‘%S’, ‘%s’, ‘%B’, ‘%b’, ‘%U’, ‘%u’ for entering and
leaving the display modes standout, bold and underline are also
available, as is the form ‘%{...%}’ for enclosing escape
sequences which display with zero width.
list-rows-first
This style is tested in the same way as the list-packed style
and determines whether matches are to be listed in a rows-first
fashion as if the LIST_ROWS_FIRST option were set.
list-suffixes
This style is used by the function that completes filenames. If
it is true, and completion is attempted on a string containing
multiple partially typed pathname components, all ambiguous com-
ponents will be shown. Otherwise, completion stops at the first
ambiguous component.
list-separator
The value of this style is used in completion listing to sepa-
rate the string to complete from a description when possible
(e.g. when completing options). It defaults to ‘--’ (two
hyphens).
local This is for use with functions that complete URLs for which the
corresponding files are available directly from the filing sys-
tem. Its value should consist of three strings: a hostname, the
path to the default web pages for the server, and the directory
name used by a user placing web pages within their home area.
For example:
zstyle â€â€™:completion:*â€â€™ local toast \
/var/http/public/toast public_html
Completion after ‘http://toast/stuff/’ will look for files in
the directory /var/http/public/toast/stuff, while completion
after ‘http://toast/~yousir/’ will look for files in the direc-
tory ~yousir/public_html.
mail-directory
If set, zsh will assume that mailbox files can be found in the
directory specified. It defaults to ‘~/Mail’.
match-original
This is used by the _match completer. If it is set to only,
_match will try to generate matches without inserting a ‘*’ at
the cursor position. If set to any other non-empty value, it
will first try to generate matches without inserting the ‘*’ and
if that yields no matches, it will try again with the ‘*’
inserted. If it is unset or set to the empty string, matching
will only be performed with the ‘*’ inserted.
matcher
This style is tested separately for each tag valid in the cur-
rent context. Its value is added to any match specifications
given by the matcher-list style. It should be in the form
described in the section ‘Matching Control’ in zshcompwid(1).
matcher-list
This style can be set to a list of match specifications that are
to be applied everywhere. Match specifications are described in
the section ‘Matching Control’ in zshcompwid(1). The completion
system will try them one after another for each completer
selected. For example, to try first simple completion and, if
that generates no matches, case-insensitive completion:
zstyle â€â€™:completion:*â€â€™ matcher-list â€â€™â€â€™ â€â€™m:{a-zA-Z}={A-Za-z}â€â€™
By default each specification replaces the previous one; how-
ever, if a specification is prefixed with +, it is added to the
existing list. Hence it is possible to create increasingly gen-
eral specifications without repetition:
zstyle â€â€™:completion:*â€â€™ matcher-list â€â€™â€â€™ â€â€™+m{a-Z}={A-Z}â€â€™ â€â€™+m{A-Z}={a-z}â€â€™
It is possible to create match specifications valid for particu-
lar completers by using the third field of the context. For
example, to use the completers _complete and _prefix but only
allow case-insensitive completion with _complete:
zstyle â€â€™:completion:*â€â€™ completer _complete _prefix
zstyle â€â€™:completion:*:complete:*â€â€™ matcher-list \
â€â€™â€â€™ â€â€™m:{a-zA-Z}={A-Za-z}â€â€™
User-defined names, as explained for the completer style, are
available. This makes it possible to try the same completer
more than once with different match specifications each time.
For example, to try normal completion without a match specifica-
tion, then normal completion with case-insensitive matching,
then correction, and finally partial-word completion:
zstyle â€â€™:completion:*â€â€™ completer _complete _correct _complete:foo
zstyle â€â€™:completion:*:complete:*â€â€™ matcher-list \
â€â€™â€â€™ â€â€™m:{a-zA-Z}={A-Za-z}â€â€™
zstyle â€â€™:completion:*:foo:*â€â€™ matcher-list \
â€â€™m:{a-zA-Z}={A-Za-z} r:|[-_./]=* r:|=*â€â€™
If the style is unset in any context no match specification is
applied. Note also that some completers such as _correct and
_approximate do not use the match specifications at all, though
these completers will only ever called once even if the
matcher-list contains more than one element.
Where multiple specifications are useful, note that the entire
completion is done for each element of matcher-list, which can
quickly reduce the shell’s performance. As a rough rule of
thumb, one to three strings will give acceptable performance.
On the other hand, putting multiple space-separated values into
the same string does not have an appreciable impact on perfor-
mance.
max-errors
This is used by the _approximate and _correct completer func-
tions to determine the maximum number of errors to allow. The
completer will try to generate completions by first allowing one
error, then two errors, and so on, until either a match or
matches were found or the maximum number of errors given by this
style has been reached.
If the value for this style contains the string ‘numeric’, the
completer function will take any numeric argument as the maximum
number of errors allowed. For example, with
zstyle â€â€™:completion:*:approximate:::â€â€™ max-errors 2 numeric
two errors are allowed if no numeric argument is given, but with
a numeric argument of six (as in ‘ESC-6 TAB’), up to six errors
are accepted. Hence with a value of ‘0 numeric’, no correcting
completion will be attempted unless a numeric argument is given.
If the value contains the string ‘not-numeric’, the completer
will not try to generate corrected completions when given a
numeric argument, so in this case the number given should be
greater than zero. For example, ‘2 not-numeric’ specifies that
correcting completion with two errors will usually be performed,
but if a numeric argument is given, correcting completion will
not be performed.
The default value for this style is ‘2 numeric’.
max-matches-width
This style is used to determine the trade off between the width
of the display used for matches and the width used for their
descriptions when the verbose style is in effect. The value
gives the number of display columns to reserve for the matches.
The default is half the width of the screen.
This has the most impact when several matches have the same
description and so will be grouped together. Increasing the
style will allow more matches to be grouped together; decreasing
it will allow more of the description to be visible.
menu If this is true in the context of any of the tags defined for
the current completion menu completion will be used. The value
for a specific tag will take precedence over that for the
‘default’ tag.
If none of the values found in this way is true but at least one
is set to ‘auto’, the shell behaves as if the AUTO_MENU option
is set.
If one of the values is explicitly set to false, menu completion
will be explicitly turned off, overriding the MENU_COMPLETE
option and other settings.
In the form ‘yes=num’, where ‘yes’ may be any of the true values
(‘yes’, ‘true’, ‘on’ and ‘1’), menu completion will be turned on
if there are at least num matches. In the form ‘yes=long’, menu
completion will be turned on if the list does not fit on the
screen. This does not activate menu completion if the widget
normally only lists completions, but menu completion can be
activated in that case with the value ‘yes=long-list’ (Typi-
cally, the value ‘select=long-list’ described later is more use-
ful as it provides control over scrolling.)
Similarly, with any of the ‘false’ values (as in ‘no=10’), menu
completion will not be used if there are num or more matches.
The value of this widget also controls menu selection, as imple-
mented by the zsh/complist module. The following values may
appear either alongside or instead of the values above.
If the value contains the string ‘select’, menu selection will
be started unconditionally.
In the form ‘select=num’, menu selection will only be started if
there are at least num matches. If the values for more than one
tag provide a number, the smallest number is taken.
Menu selection can be turned off explicitly by defining a value
containing the string‘no-select’.
It is also possible to start menu selection only if the list of
matches does not fit on the screen by using the value
‘select=long’. To start menu selection even if the current wid-
get only performs listing, use the value ‘select=long-list’.
To turn on menu completion or menu selection when a there are a
certain number of matches or the list of matches does not fit on
the screen, both of ‘yes=’ and ‘select=’ may be given twice,
once with a number and once with ‘long’ or ‘long-list’.
Finally, it is possible to activate two special modes of menu
selection. The word ‘interactive’ in the value causes interac-
tive mode to be entered immediately when menu selection is
started; see the description of the zsh/complist module in zsh-
modules(1).RE for a description of interactive mode. Including
the string ‘search’ does the same for incremental search mode.
To select backward incremental search, include the string
‘search-backward’. )
muttrc If set, gives the location of the mutt configuration
file. It defaults to ‘~/.muttrc’.
numbers
This is used with the jobs tag. If it is ‘true’, the
shell will complete job numbers instead of the shortest
unambiguous prefix of the job command text. If the value
is a number, job numbers will only be used if that many
words from the job descriptions are required to resolve
ambiguities. For example, if the value is ‘1’, strings
will only be used if all jobs differ in the first word on
their command lines.
old-list
This is used by the _oldlist completer. If it is set to
‘always’, then standard widgets which perform listing
will retain the current list of matches, however they
were generated; this can be turned off explicitly with
the value ‘never’, giving the behaviour without the
_oldlist completer. If the style is unset, or any other
value, then the existing list of completions is displayed
if it is not already; otherwise, the standard completion
list is generated; this is the default behaviour of
_oldlist. However, if there is an old list and this
style contains the name of the completer function that
generated the list, then the old list will be used even
if it was generated by a widget which does not do list-
ing.
For example, suppose you type ^Xc to use the _cor-
rect_word widget, which generates a list of corrections
for the word under the cursor. Usually, typing ^D would
generate a standard list of completions for the word on
the command line, and show that. With _oldlist, it will
instead show the list of corrections already generated.
As another example consider the _match completer: with
the insert-unambiguous style set to ‘true’ it inserts
only a common prefix string, if there is any. However,
this may remove parts of the original pattern, so that
further completion could produce more matches than on the
first attempt. By using the _oldlist completer and set-
ting this style to _match, the list of matches generated
on the first attempt will be used again.
old-matches
This is used by the _all_matches completer to decide if
an old list of matches should be used if one exists.
This is selected by one of the ‘true’ values or by the
string ‘only’. If the value is ‘only’, _all_matches will
only use an old list and won’t have any effect on the
list of matches currently being generated.
If this style is set it is generally unwise to call the
_all_matches completer unconditionally. One possible use
is for either this style or the completer style to be
defined with the -e option to zstyle to make the style
conditional.
old-menu
This is used by the _oldlist completer. It controls how
menu completion behaves when a completion has already
been inserted and the user types a standard completion
key such as TAB. The default behaviour of _oldlist is
that menu completion always continues with the existing
list of completions. If this style is set to ‘false’,
however, a new completion is started if the old list was
generated by a different completion command; this is the
behaviour without the _oldlist completer.
For example, suppose you type ^Xc to generate a list of
corrections, and menu completion is started in one of the
usual ways. Usually, or with this style set to false,
typing TAB at this point would start trying to complete
the line as it now appears. With _oldlist, it instead
continues to cycle through the list of corrections.
original
This is used by the _approximate and _correct completers
to decide if the original string should be added as a
possible completion. Normally, this is done only if
there are at least two possible corrections, but if this
style is set to ‘true’, it is always added. Note that
the style will be examined with the completer field in
the context name set to correct-num or approximate-num,
where num is the number of errors that were accepted.
packageset
This style is used when completing arguments of the
Debian ‘dpkg’ program. It contains an override for the
default package set for a given context. For example,
zstyle â€â€™:completion:*:complete:dpkg:option--status-1:*â€â€™ \
packageset avail
causes available packages, rather than only installed
packages, to be completed for ‘dpkg --status’.
path The function that completes color names uses this style
with the colors tag. The value should be the pathname of
a file containing color names in the format of an X11
rgb.txt file. If the style is not set but this file is
found in one of various standard locations it will be
used as the default.
pine-directory
If set, specifies the directory containing PINE mailbox
files. It defaults to ‘~/mail’.
ports A list of Internet service names (network ports) to com-
plete. If this is not set, service names are taken from
the file ‘/etc/services’.
prefix-hidden
This is used for certain completions which share a common
prefix, for example command options beginning with
dashes. If it is ‘true’, the prefix will not be shown in
the list of matches.
The default value for this style is ‘false’.
prefix-needed
This, too, is used for matches with a common prefix. If
it is set to ‘true’ this common prefix must be typed by
the user to generate the matches. In the case of command
options, this means that the initial ‘-’, ‘+’, or ‘--’
must be typed explicitly before option names will be com-
pleted.
The default value for this style is ‘true’.
preserve-prefix
This style is used when completing path names. Its value
should be a pattern matching an initial prefix of the
word to complete that should be left unchanged under all
circumstances. For example, on some Unices an initial
‘//’ (double slash) has a special meaning; setting this
style to the string ‘//’ will preserve it. As another
example, setting this style to ‘?:/’ under Cygwin would
allow completion after ‘a:/...’ and so on.
range This is used by the _history completer and the _his-
tory_complete_word bindable command to decide which words
should be completed.
If it is a singe number, only the last N words from the
history will be completed.
If it is a range of the form ‘max:slice’, the last slice
words will be completed; then if that yields no matches,
the slice words before those will be tried and so on.
This process stops either when at least one match was
been found, or max words have been tried.
The default is to complete all words from the history at
once.
regular
This style is used by the _expand_alias completer and
bindable command. If set to ‘true’ (the default), regu-
lar aliases will be expanded but only in command posi-
tion. If it is set to ‘false’, regular aliases will
never be expanded. If it is set to ‘always’, regular
aliases will be expanded even if not in command position.
remote-access
If set to false, certain commands will be prevented from
making Internet connections to retrieve remote informa-
tion. This includes the completion for the CVS command.
It is not always possible to know if connections are in
fact to a remote site, so some may be prevented unneces-
sarily.
remove-all-dups
The _history_complete_word bindable command and the _his-
tory completer use this to decide if all duplicate
matches should be removed, rather than just consecutive
duplicates.
select-prompt
If this is set for the default tag, its value will be
displayed during menu selection (see the menu style
above) when the completion list does not fit on the
screen as a whole. The same escapes as for the
list-prompt style are understood, except that the numbers
refer to the match or line the mark is on. A default
prompt is used when the value is the empty string.
select-scroll
This style is tested for the default tag and determines
how a completion list is scrolled during a menu selection
(see the menu style above) when the completion list does
not fit on the screen as a whole. If the value is ‘0’
(zero), the list is scrolled by half-screenfuls; if it is
a positive integer, the list is scrolled by the given
number of lines; if it is a negative number, the list is
scrolled by a screenful minus the absolute value of the
given number of lines. The default is to scroll by sin-
gle lines.
separate-sections
This style is used with the manuals tag when completing
names of manual pages. If it is ‘true’, entries for dif-
ferent sections are added separately using tag names of
the form ‘manual.X’, where X is the section number. When
the group-name style is also in effect, pages from dif-
ferent sections will appear separately. This style is
also used similarly with the words style when completing
words for the dict command. It allows words from differ-
ent dictionary databases to be added separately. The
default for this style is ‘false’.
single-ignored
This is used by the _ignored completer when there is only
one match. If its value is ‘show’, the single match will
be displayed but not inserted. If the value is ‘menu’,
then the single match and the original string are both
added as matches and menu completion is started, making
it easy to select either of them.
sort Many completion widgets call _description at some point
which decides whether the matches are added sorted or
unsorted (often indirectly via _wanted or _requested).
This style can be set explicitly to one of the usual true
or false values as an override. If it is not set for the
context, the standard behaviour of the calling widget is
used.
The style is tested first against the full context
including the tag, and if that fails to produce a value
against the context without the tag.
If the calling widget explicitly requests unsorted
matches, this is usually honoured. However, the default
(unsorted) behaviour of completion for the command his-
tory may be overridden by setting the style to true.
In the _expand completer, if it is set to ‘true’, the
expansions generated will always be sorted. If it is set
to ‘menu’, then the expansions are only sorted when they
are offered as single strings but not in the string con-
taining all possible expansions.
special-dirs
Normally, the completion code will not produce the direc-
tory names ‘.’ and ‘..’ as possible completions. If this
style is set to ‘true’, it will add both ‘.’ and ‘..’ as
possible completions; if it is set to ‘..’, only ‘..’
will be added.
The following example sets special-dirs to ‘..’ when the
current prefix is empty, is a single ‘.’, or consists
only of a path beginning with ‘../’. Otherwise the value
is ‘false’.
zstyle -e â€â€™:completion:*â€â€™ special-dirs \
â€â€™[[ $PREFIX = (../)#(|.|..) ]] && reply=(..)â€â€™
squeeze-slashes
If set to ‘true’, sequences of slashes in filename paths
(for example in ‘foo//bar’) will be treated as a single
slash. This is the usual behaviour of UNIX paths. How-
ever, by default the file completion function behaves as
if there were a ‘*’ between the slashes.
stop If set to ‘true’, the _history_complete_word bindable
command will stop once when reaching the beginning or end
of the history. Invoking _history_complete_word will
then wrap around to the opposite end of the history. If
this style is set to ‘false’ (the default), _history_com-
plete_word will loop immediately as in a menu completion.
strip-comments
If set to ‘true’, this style causes non-essential comment
text to be removed from completion matches. Currently it
is only used when completing e-mail addresses where it
removes any display name from the addresses, cutting them
down to plain user@host form.
subst-globs-only
This is used by the _expand completer. If it is set to
‘true’, the expansion will only be used if it resulted
from globbing; hence, if expansions resulted from the use
of the substitute style described below, but these were
not further changed by globbing, the expansions will be
rejected.
The default for this style is ‘false’.
substitute
This boolean style controls whether the _expand completer
will first try to expand all substitutions in the string
(such as ‘$(...)’ and ‘${...}’).
The default is ‘true’.
suffix This is used by the _expand completer if the word starts
with a tilde or contains a parameter expansion. If it is
set to ‘true’, the word will only be expanded if it
doesn’t have a suffix, i.e. if it is something like
‘~foo’ or ‘$foo’ rather than ‘~foo/’ or ‘$foo/bar’,
unless that suffix itself contains characters eligible
for expansion. The default for this style is ‘true’.
tag-order
This provides a mechanism for sorting how the tags avail-
able in a particular context will be used.
The values for the style are sets of space-separated
lists of tags. The tags in each value will be tried at
the same time; if no match is found, the next value is
used. (See the file-patterns style for an exception to
this behavior.)
For example:
zstyle â€â€™:completion:*:complete:-command-:*â€â€™ tag-order \
â€â€™commands functionsâ€â€™
specifies that completion in command position first
offers external commands and shell functions. Remaining
tags will be tried if no completions are found.
In addition to tag names, each string in the value may
take one of the following forms:
- If any value consists of only a hyphen, then only
the tags specified in the other values are gener-
ated. Normally all tags not explicitly selected
are tried last if the specified tags fail to gen-
erate any matches. This means that a single
value consisting only of a single hyphen turns
off completion.
! tags...
A string starting with an exclamation mark speci-
fies names of tags that are not to be used. The
effect is the same as if all other possible tags
for the context had been listed.
tag:label ...
Here, tag is one of the standard tags and label
is an arbitrary name. Matches are generated as
normal but the name label is used in contexts
instead of tag. This is not useful in words
starting with !.
If the label starts with a hyphen, the tag is
prepended to the label to form the name used for
lookup. This can be used to make the completion
system try a certain tag more than once, supply-
ing different style settings for each attempt;
see below for an example.
tag:label:description
As before, but description will replace the ‘%d’
in the value of the format style instead of the
default description supplied by the completion
function. Spaces in the description must be
quoted with a backslash. A ‘%d’ appearing in
description is replaced with the description
given by the completion function.
In any of the forms above the tag may be a pattern or
several patterns in the form ‘{pat1,pat2...}’. In this
case all matching tags will be used except for any given
explicitly in the same string.
One use of these features is to try one tag more than
once, setting other styles differently on each attempt,
but still to use all the other tags without having to
repeat them all. For example, to make completion of
function names in command position ignore all the comple-
tion functions starting with an underscore the first time
completion is tried:
zstyle â€â€™:completion:*:*:-command-:*â€â€™ tag-order \
â€â€™functions:-non-comp *â€â€™ functions
zstyle â€â€™:completion:*:functions-non-compâ€â€™ ignored-patterns â€â€™_*â€â€™
On the first attempt, all tags will be offered but the
functions tag will be replaced by functions-non-comp.
The ignored-patterns style is set for this tag to exclude
functions starting with an underscore. If there are no
matches, the second value of the tag-order style is used
which completes functions using the default tag, this
time presumably including all function names.
The matches for one tag can be split into different
groups. For example:
zstyle â€â€™:completion:*â€â€™ tag-order \
â€â€™options:-long:long\ options
options:-short:short\ options
options:-single-letter:single\ letter\ optionsâ€â€™
zstyle ’:completion:*:options-long’ ignored-patterns ’[-+](|-|[^-]*)’
zstyle ’:completion:*:options-short’ ignored-patterns ’--*’ ’[-+]?’
zstyle ’:completion:*:options-single-letter’ ignored-patterns ’???*’
With the group-names style set, options beginning with
‘--’, options beginning with a single ‘-’ or ‘+’ but con-
taining multiple characters, and single-letter options
will be displayed in separate groups with different
descriptions.
Another use of patterns is to try multiple match specifi-
cations one after another. The matcher-list style offers
something similar, but it is tested very early in the
completion system and hence can’t be set for single com-
mands nor for more specific contexts. Here is how to try
normal completion without any match specification and, if
that generates no matches, try again with case-insensi-
tive matching, restricting the effect to arguments of the
command foo:
zstyle â€â€™:completion:*:*:foo:*â€â€™ tag-order â€â€™*â€â€™ â€â€™*:-caseâ€â€™
zstyle â€â€™:completion:*-caseâ€â€™ matcher â€â€™m:{a-z}={A-Z}â€â€™
First, all the tags offered when completing after foo are
tried using the normal tag name. If that generates no
matches, the second value of tag-order is used, which
tries all tags again except that this time each has -case
appended to its name for lookup of styles. Hence this
time the value for the matcher style from the second call
to zstyle in the example is used to make completion
case-insensitive.
It is possible to use the -e option of the zstyle builtin
command to specify conditions for the use of particular
tags. For example:
zstyle -e â€â€™*:-command-:*â€â€™ tag-order â€â€™
if [[ -n $PREFIX$SUFFIX ]]; then
reply=( )
else
reply=( - )
fiâ€â€™
Completion in command position will be attempted only if
the string typed so far is not empty. This is tested
using the PREFIX special parameter; see zshcompwid for a
description of parameters which are special inside com-
pletion widgets. Setting reply to an empty array pro-
vides the default behaviour of trying all tags at once;
setting it to an array containing only a hyphen disables
the use of all tags and hence of all completions.
If no tag-order style has been defined for a context, the
strings ‘(|*-)argument-* (|*-)option-* values’ and
‘options’ plus all tags offered by the completion func-
tion will be used to provide a sensible default behavior
that causes arguments (whether normal command arguments
or arguments of options) to be completed before option
names for most commands.
urls This is used together with the the urls tag by functions
completing URLs.
If the value consists of more than one string, or if the
only string does not name a file or directory, the
strings are used as the URLs to complete.
If the value contains only one string which is the name
of a normal file the URLs are taken from that file (where
the URLs may be separated by white space or newlines).
Finally, if the only string in the value names a direc-
tory, the directory hierarchy rooted at this directory
gives the completions. The top level directory should be
the file access method, such as ‘http’, ‘ftp’, ‘bookmark’
and so on. In many cases the next level of directories
will be a filename. The directory hierarchy can descend
as deep as necessary.
For example,
zstyle â€â€™:completion:*â€â€™ urls ~/.urls
mkdir -p ~/.urls/ftp/ftp.zsh.org/pub/development
allows completion of all the components of the URL
ftp://ftp.zsh.org/pub/development after suitable commands
such as ‘netscape’ or ‘lynx’. Note, however, that access
methods and files are completed separately, so if the
hosts style is set hosts can be completed without refer-
ence to the urls style.
See the description in the function _urls itself for more
information (e.g. ‘more $^fpath/_urls(N)’).
use-cache
If this is set, the completion caching layer is activated
for any completions which use it (via the _store_cache,
_retrieve_cache, and _cache_invalid functions). The
directory containing the cache files can be changed with
the cache-path style.
use-compctl
If this style is set to a string not equal to false, 0,
no, and off, the completion system may use any completion
specifications defined with the compctl builtin command.
If the style is unset, this is done only if the zsh/com-
pctl module is loaded. The string may also contain the
substring ‘first’ to use completions defined with ‘com-
pctl -T’, and the substring ‘default’ to use the comple-
tion defined with ‘compctl -D’.
Note that this is only intended to smooth the transition
from compctl to the new completion system and may disap-
pear in the future.
Note also that the definitions from compctl will only be
used if there is no specific completion function for the
command in question. For example, if there is a function
_foo to complete arguments to the command foo, compctl
will never be invoked for foo. However, the compctl ver-
sion will be tried if foo only uses default completion.
use-perl
Various parts of the function system use awk to extract
words from files or command output as this universally
available. However, many versions of awk have arbitrary
limits on the size of input. If this style is set, perl
will be used instead. This is almost always preferable
if perl is available on your system.
Currently this is only used in completions for ‘make’,
but it may be extended depending on authorial frustra-
tion.
users This may be set to a list of usernames to be completed.
If it is not set or the string on the line doesn’t match
any of the strings in t