This is zsh.info, produced by makeinfo version 4.0 from ./zsh.texi.

INFO-DIR-SECTION Utilities
START-INFO-DIR-ENTRY
* ZSH: (zsh).                     The Z Shell Manual.
END-INFO-DIR-ENTRY


File: zsh.info,  Node: Builtin Commands,  Next: Condition Codes,  Prev: Special Parameters,  Up: Completion Widgets

Builtin Commands
================

compadd [ -akqQfenUl12C ] [ -F ARRAY ]
[ -P PREFIX ] [ -S SUFFIX ]
[ -p HIDDEN-PREFIX ] [ -s HIDDEN-SUFFIX ]
[ -i IGNORED-PREFIX ] [ -I IGNORED-SUFFIX ]
[ -W FILE-PREFIX ] [ -d ARRAY ]
[ -J NAME ] [ -V NAME ] [ -X EXPLANATION ] [ -x MESSAGE ]
[ -r REMOVE-CHARS ] [ -R REMOVE-FUNC ]
[ -D ARRAY ] [ -O ARRAY ] [ -A ARRAY ]
[ -E NUMBER ]
[ -M MATCH-SPEC ] [ - ] [ WORDS ... ]
     This builtin command can be used to add matches directly and
     control all the information the completion code stores with each
     possible match. The return value is zero if at least one match was
     added and non-zero if no matches were added.

     The completion code breaks the string to complete into seven
     fields in the order:

          <IPRE><APRE><HPRE><WORD><HSUF><ASUF><ISUF>

     The first field is an ignored prefix taken from the command line,
     the contents of the IPREFIX parameter plus the string given with
     the -i option. With the -U option, only the string from the -i
     option is used. The field <APRE> is an optional prefix string
     given with the -P option.  The <HPRE> field is a string that is
     considered part of the match but that should not be shown when
     listing completions, given with the -p option; for example,
     functions that do filename generation might specify a common path
     prefix this way.  <WORD> is the part of the match that should
     appear in the list of completions, i.e. one of the WORDS given at
     the end of the compadd command line. The suffixes <HSUF>, <ASUF>
     and <ISUF> correspond to the prefixes <HPRE>, <APRE> and <IPRE>
     and are given by the options -s, -S and -I, respectively.

     The supported flags are:

    -P PREFIX
          This gives a string to be inserted before the given WORDS.
          The string given is not considered as part of the match and
          any shell metacharacters in it will not be quoted when the
          string is inserted.

    -S SUFFIX
          Like -P, but gives a string to be inserted after the match.

    -p HIDDEN-PREFIX
          This gives a string that should be inserted into the command
          line before the match but that should not appear in the list
          of matches. Unless the -U option is given, this string must
          be matched as part of the string on the command line.

    -s HIDDEN-SUFFIX
          Like `-p', but gives a string to insert after the match.

    -i IGNORED-PREFIX
          This gives a string to insert into the command line just
          before any string given with the `-P' option.  Without `-P'
          the string is inserted before the string given with `-p' or
          directly before the match.

    -I IGNORED-SUFFIX
          Like -i, but gives an ignored suffix.

    -a
          With this flag the WORDS are taken as names of arrays and the
          possible matches are their values.  If only some elements of
          the arrays are needed, the WORDS may also contain subscripts,
          as in `foo[2,-1]'.

    -k
          With this flag the WORDS are taken as names of associative
          arrays and the possible matches are their keys.  As for -a,
          the WORDS may also contain subscripts, as in `foo[(R)*bar*]'.

    -d ARRAY
          This adds per-match display strings. The ARRAY should contain
          one element per WORD given. The completion code will then
          display the first element instead of the first WORD, and so
          on. The ARRAY may be given as the name of an array parameter
          or directly as a space-separated list of words in parentheses.

          If there are fewer display strings than WORDS, the leftover
          WORDS will be displayed unchanged and if there are more
          display strings than WORDS, the leftover display strings will
          be silently ignored.

    -l
          This option only has an effect if used together with the -d
          option. If it is given, the display strings are listed one
          per line, not arrayed in columns.

    -J NAME
          Gives the name of the group of matches the words should be
          stored in.

    -V NAME
          Like -J but naming a unsorted group. These are in a different
          name space than groups created with the -J flag.

    -1
          If given together with the -V option, makes only consecutive
          duplicates in the group be removed. If combined with the -J
          option, this has no visible effect. Note that groups with and
          without this flag are in different name spaces.

    -2
          If given together with the -J or -V option, makes all
          duplicates be kept. Again, groups with and without this flag
          are in different name spaces.

    -X EXPLANATION
          The EXPLANATION string will be printed with the list of
          matches, above the group currently selected.

    -x MESSAGE
          Like -X, but the MESSAGE will be printed even if there are no
          matches in the group.

    -q
          The suffix given with -S will be automatically 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.

    -r REMOVE-CHARS
          This is a more versatile form of the -q option.  The suffix
          given with -S or the slash automatically added after
          completing directories will be automatically removed if the
          next character typed inserts one of the characters given in
          the REMOVE-CHARS.  This string is parsed as a characters
          class and understands the backslash sequences used by the
          print command.  For example, `-r "a-z\t"' removes the suffix
          if the next character typed inserts a lowercase character or
          a TAB, and `-r "^0-9"' removes the suffix if the next
          character typed inserts anything but a digit. One extra
          backslash sequence is understood in this string: `\-' stands
          for all characters that insert nothing. Thus `-S "=" -q' is
          the same as `-S "=" -r "= \t\n\-"'.

          This option may also be used without the -S option; then any
          automatically added space will be removed when one of the
          characters in the list is typed.

    -R REMOVE-FUNC
          This is another form of the -r option. When a suffix has been
          inserted and the completion accepted, the function
          REMOVE-FUNC will be called after the next character typed.
          It is passed the length of the suffix as an argument and can
          use the special parameters available in ordinary
          (non-completion) zle widgets (see *Note Zsh Line Editor::) to
          analyse and modify the command line.

    -f
          If this flag is given, all of the matches built from WORDS are
          marked as being the names of files.  They are not required to
          be actual filenames, but if they are, and the option
          LIST_TYPES is set, the characters describing the types of the
          files in the completion lists will be shown. This also forces
          a slash to be added when the name of a directory is completed.

    -e
          This flag can be used to tell the completion code that the
          matches added are parameter names for a parameter expansion.
          This will make the AUTO_PARAM_SLASH and AUTO_PARAM_KEYS
          options be used for the matches.

    -W FILE-PREFIX
          This string is a pathname that will be prepended to each of
          the matches formed by the given WORDS together with any
          prefix specified by the -p option to form a complete filename
          for testing.  Hence it is only useful if combined with the -f
          flag, as the tests will not otherwise be performed.

    -F ARRAY
          Specifies an array containing patterns. Words matching one of
          these patterns are ignored, i.e. not considered to be
          possible matches.

          The ARRAY may be the name of an array parameter or a list of
          literal patterns enclosed in parentheses and quoted, as in
          `-F "(*?.o *?.h)"'. If the name of an array is given, the
          elements of the array are taken as the patterns.

    -Q
          This flag instructs the completion code not to quote any
          metacharacters in the words when inserting them into the
          command line.

    -M MATCH-SPEC
          This gives local match specifications as described below in
          *Note Matching Control::. This option may be given more than
          once. In this case all MATCH-SPECs given are concatenated
          with spaces between them to form the specification string to
          use.  Note that they will only be used if the -U option is
          not given.

    -n
          Specifies that the words added are to be used as possible
          matches, but are not to appear in the completion listing.

    -U
          If this flag is given, all words given will be accepted and
          no matching will be done by the completion code. Normally
          this is used in functions that do the matching themselves.

    -O ARRAY
          If this option is given, the WORDS are _not_ added to the set
          of possible completions.  Instead, matching is done as usual
          and all of the WORDS given as arguments that match the string
          on the command line will be stored in the array parameter
          whose name is given as ARRAY.

    -A ARRAY
          As the -O option, except that instead of those of the WORDS
          which match being stored in ARRAY, the strings generated
          internally by the completion code are stored. For example,
          with a matching specification of `-M "L:|no="', the string
          `nof' on the command line and the string `foo' as one of the
          WORDS, this option stores the string `nofoo' in the array,
          whereas the -O option stores the `foo' originally given.

    -D ARRAY
          As with -O, the WORDS are not added to the set of possible
          completions.  Instead, the completion code tests whether each
          WORD in turn matches what is on the line.  If the N'th WORD
          does not match, the N'th element of the ARRAY is removed.
          Elements for which the corresponding WORD is matched are
          retained.

    -C
          This option adds a special match which expands to all other
          matches when inserted into the line, even those that are
          added after this option is used.  Together with the -d option
          it is possible to specify a string that should be displayed
          in the list for this special match.  If no string is given,
          it will be shown as a string containing the strings that
          would be inserted for the other matches, truncated to the
          width of the screen.

    -E
          This option adds NUMBER empty matches after the WORDS have
          been added.  An empty match takes up space in completion
          listings but will never be inserted in the line and can't be
          selected with menu completion or menu selection.  This makes
          empty matches only useful to format completion lists and to
          make explanatory string be shown in completion lists (since
          empty matches can be given display strings with the -d
          option).  And because all but one empty string would
          otherwise be removed, this option implies the -V and -2
          options (even if an explicit -J option is given).

    -
    --
          This flag ends the list of flags and options. All arguments
          after it will be taken as the words to use as matches even if
          they begin with hyphens.

     Except for the -M flag, if any of these flags is given more than
     once, the first one (and its argument) will be used.

compset -p NUMBER
compset -P [ NUMBER ] PATTERN
compset -s NUMBER
compset -S [ NUMBER ] PATTERN
compset -n BEGIN [ END ]
compset -N BEG-PAT [ END-PAT ]
compset -q
     This command simplifies modification of the special parameters,
     while its return value allows tests on them to be carried out.

     The options are:

    -p NUMBER
          If the contents of the PREFIX parameter is longer than NUMBER
          characters, the first NUMBER characters are removed from it
          and appended to the contents of the IPREFIX parameter.

    -P [ NUMBER ] PATTERN
          If the value of the PREFIX parameter begins with anything that
          matches the PATTERN, the matched portion is removed from
          PREFIX and appended to IPREFIX.

          Without the optional NUMBER, the longest match is taken, but
          if NUMBER is given, anything up to the NUMBER'th match is
          moved.  If the NUMBER is negative, the NUMBER'th longest
          match is moved. For example, if PREFIX contains the string
          `a=b=c', then compset -P '*\=' will move the string `a=b='
          into the IPREFIX parameter, but compset -P 1 '*\=' will move
          only the string `a='.

    -s NUMBER
          As -p, but transfer the last NUMBER characters from the value
          of SUFFIX to the front of the value of ISUFFIX.

    -S [ NUMBER ] PATTERN
          As -P, but match the last portion of SUFFIX and transfer the
          matched portion to the front of the value of ISUFFIX.

    -n BEGIN [ END ]
          If the current word position as specified by the parameter
          CURRENT is greater than or equal to BEGIN, anything up to the
          BEGIN'th word is removed from the words array and the value
          of the parameter CURRENT is decremented by BEGIN.

          If the optional END is given, the modification is done only if
          the current word position is also less than or equal to END.
          In this case, the words from position END onwards are also
          removed from the words array.

          Both BEGIN and END may be negative to count backwards from
          the last element of the words array.

    -N BEG-PAT [ END-PAT ]
          If one of the elements of the words array before the one at
          the index given by the value of the parameter CURRENT matches
          the pattern BEG-PAT, all elements up to and including the
          matching one are removed from the words array and the value
          of CURRENT is changed to point to the same word in the
          changed array.

          If the optional pattern END-PAT is also given, and there is an
          element in the words array matching this pattern, the
          parameters are modified only if the index of this word is
          higher than the one given by the CURRENT parameter (so that
          the matching word has to be after the cursor). In this case,
          the words starting with the one matching end-pat are also
          removed from the words array. If words contains no word
          matching END-PAT, the testing and modification is performed
          as if it were not given.

    -q
          The word currently being completed is split on spaces into
          separate words, respecting the usual shell quoting
          conventions.  The resulting words are stored in the words
          array, and CURRENT, PREFIX, SUFFIX, QIPREFIX, and QISUFFIX
          are modified to reflect the word part that is completed.

     In all the above cases the return value is zero if the test
     succeeded and the parameters were modified and non-zero otherwise.
     This allows one to use this builtin in tests such as:

          if compset -P '*\='; then ...

     This forces anything up to and including the last equal sign to be
     ignored by the completion code.

compcall [ -TD ]
     This allows the use of completions defined with the compctl builtin
     from within completion widgets.  The list of matches will be
     generated as if one of the non-widget completion function
     (complete-word, etc.)  had been called, except that only compctls
     given for specific commands are used. To force the code to try
     completions defined with the -T option of compctl and/or the
     default completion (whether defined by compctl -D or the builtin
     default) in the appropriate places, the -T and/or -D flags can be
     passed to compcall.

     The return value can be used to test if a matching compctl
     definition was found. It is non-zero if a compctl was found and
     zero otherwise.

     Note that this builtin is defined by the zsh/compctl module.


File: zsh.info,  Node: Condition Codes,  Next: Matching Control,  Prev: Builtin Commands,  Up: Completion Widgets

Condition Codes
===============

The following additional condition codes for use within the [[ ... ]]
construct are available in completion widgets.  These work on the
special parameters.  All of these tests can also be performed by the
compset builtin, but in the case of the condition codes the contents of
the special parameters are not modified.

-prefix [ NUMBER ] PATTERN
     true if the test for the -P option of compset would succeed.

-suffix [ NUMBER ] PATTERN
     true if the test for the -S option of compset would succeed.

-after BEG-PAT
     true if the test of the -N option with only the BEG-PAT given
     would succeed.

-between BEG-PAT END-PAT
     true if the test for the -N option with both patterns would
     succeed.


File: zsh.info,  Node: Matching Control,  Next: Completion Widget Example,  Prev: Condition Codes,  Up: Completion Widgets

Matching Control
================

It is possible by use of the -M option of the compadd builtin command
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). Note that this is not used if the command line contains a
glob pattern and the GLOB_COMPLETE option is set or the pattern_match
of the compstate special association is set to a non-empty string.

The MATCH-SPEC given as the argument to the -M option (see *Note
Builtin Commands::) consists of one or more matching descriptions
separated by whitespace.  Each description consists of a letter
followed by a colon and 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 MATCH-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.

m:LPAT=TPAT
M:LPAT=TPAT
     Here, LPAT is a pattern that matches on the command line,
     corresponding to TPAT which matches in the trial completion.

l:LANCHOR|LPAT=TPAT
L:LANCHOR|LPAT=TPAT
l:LANCHOR||RANCHOR=TPAT
L:LANCHOR||RANCHOR=TPAT
b:LPAT=TPAT
B:LPAT=TPAT
     These letters are for patterns that are anchored by another
     pattern on the left side. Matching for LPAT and TPAT is as for m
     and M, but the pattern LPAT matched on the command line must be
     preceded by the pattern LANCHOR.  The LANCHOR 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.

     If no LPAT is given but a RANCHOR is, this matches the gap between
     substrings matched by LANCHOR and RANCHOR. Unlike LANCHOR, the
     RANCHOR only needs to match the trial completion string.

     The b and B forms are similar to l and L with an empty anchor, but
     need to match only the beginning of the trial completion or the
     word on the command line, respectively.

r:LPAT|RANCHOR=TPAT
R:LPAT|RANCHOR=TPAT
r:LANCHOR||RANCHOR=TPAT
R:LANCHOR||RANCHOR=TPAT
e:LPAT=TPAT
E:LPAT=TPAT
     As l, L, b and B, with the difference that the command line and
     trial completion patterns are anchored on the right side.  Here an
     empty RANCHOR and the e and E forms force the match to the end of
     the trial completion or command line string.

Each LPAT, TPAT or 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 ! and ^ 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 `m:{a-z}={A-Z}'.  More than one pair
of classes can occur, in which case the first class before the =
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 TPAT may also be one or two stars, `*' or `**'. 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); in the case of a single star, the 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.
With two stars, substrings matched by the anchor can be matched, too.

Examples:

The keys of the options association defined by the parameter module are
the option names in all-lowercase form, without underscores, and
without the optional no at the beginning even though the builtins
setopt and unsetopt understand option names with uppercase letters,
underscores, and the optional no.  The following alters the matching
rules so that the prefix 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:

     compadd -M 'L:|[nN][oO]= M:_= M:{A-Z}={a-z}' - \
       ${(k)options}

The first part says that the pattern `[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 (L and M) guarantees
that what has already been typed on the command line (in particular the
prefix no) will not be deleted.

Note that the use of L in the first part means that it matches only
when at the beginning of both the command line string and the trial
completion. I.e., the string `_NO_f' would not be completed to
`_NO_foo', nor would `NONO_f' be completed to `NONO_foo' because of the
leading underscore or the second `NO' on the line which makes the
pattern fail even though they are otherwise ignored. To fix this, one
would use `B:[nN][oO]=' instead of the first part. As described above,
this matches at the beginning of the trial completion, independent of
other characters or substrings at the beginning of the command line
word which are ignored by the same or other MATCH-SPECs.

The second example makes completion case insensitive.  This is just the
same as in the option example, except here we wish to retain the
characters in the list of completions:

     compadd -M 'm:{a-z}={A-Z}' ...

This makes lowercase letters match their uppercase counterparts.  To
make uppercase letters match the lowercase forms as well:

     compadd -M 'm:{a-zA-Z}={A-Za-z}' ...

A nice example for the use of * patterns is partial word completion.
Sometimes you would like to make strings like `c.s.u' complete to
strings like `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. `comp', `source' and `unix' in
this example, is to be completed from separate sets of matches is a
different problem to be solved by the implementation of the completion
widget.  The example can be handled by:

     compadd -M 'r:|.=* r:|=*' \
       - comp.sources.unix comp.sources.misc ...

The first specification says that LPAT is the empty string, while
ANCHOR is a dot; TPAT is *, so this can match anything except for the
`.' from the anchor in the trial completion word.  So in `c.s.u', the
matcher sees `c', followed by the empty string, followed by the anchor
`.', and likewise for the second dot, and replaces the empty strings
before the anchors, giving `c[omp].s[ources].u[nix]', where the last
part of the completion is just as normal.

With the pattern shown above, the string `c.u' could not be completed
to `comp.sources.unix' because the single star means that no dot
(matched by the anchor) can be skipped. By using two stars as in
`r:|.=**', however, `c.u' could be completed to `comp.sources.unix'.
This also shows that in some cases, especially if the anchor is a real
pattern, like a character class, the form with two stars may result in
more matches than one would like.

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

     compadd -M 'r:|[.,_-]=* r:|=*' ...

allows one to complete words with abbreviations before any of the
characters in the square brackets.  For example, to complete
veryverylongfile.c rather than veryverylongheader.h with the above in
effect, you can just type very.c before attempting completion.

The specifications with both a left and a right anchor are useful to
complete partial words whose parts are not separated by some special
character. For example, in some places strings have to be completed
that are formed `LikeThis' (i.e. the separate parts are determined by a
leading uppercase letter) or maybe one has to complete strings with
trailing numbers. Here one could use the simple form with only one
anchor as in:

     compadd -M 'r:|[A-Z0-9]=* r:|=*' LikeTHIS FooHoo 5foo123 5bar234

But with this, the string `H' would neither complete to `FooHoo' nor to
`LikeTHIS' because in each case there is an uppercase letter before the
`H' and that is matched by the anchor. Likewise, a `2' would not be
completed. In both cases this could be changed by using
`r:|[A-Z0-9]=**', but then `H' completes to both `LikeTHIS' and
`FooHoo' and a `2' matches the other strings because characters can be
inserted before every uppercase letter and digit. To avoid this one
would use:

     compadd -M 'r:[^A-Z0-9]||[A-Z0-9]=** r:|=*' \
         LikeTHIS FooHoo foo123 bar234

By using these two anchors, a `H' matches only uppercase `H's that are
immediately preceded by something matching the left anchor `[^A-Z0-9]'.
The effect is, of course, that `H' matches only the string `FooHoo', a
`2' matches only `bar234' and so on.

When using the completion system (see *Note Completion System::), users
can define match specifications that are to be used for specific
contexts by using the matcher and matcher-list styles. The values for
the latter will be used everywhere.


File: zsh.info,  Node: Completion Widget Example,  Prev: Matching Control,  Up: Completion Widgets

Completion Widget Example
=========================

The first step is to define the widget:

     zle -C complete complete-word complete-files

Then the widget can be bound to a key using the bindkey builtin command:

     bindkey '^X\t' complete

After that the shell function complete-files will be invoked after
typing control-X and TAB. The function should then generate the
matches, e.g.:

     complete-files () { compadd - * }

This function will complete files in the current directory matching the
current word.


File: zsh.info,  Node: Completion System,  Next: Completion Using compctl,  Prev: Completion Widgets,  Up: Top

Completion System
*****************

Description
===========

This describes the shell code for the new completion system.  It
consists 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
completion behaviour and may be bound to keystrokes, are referred to as
`widgets'.

* Menu:

* Initialization::
* Completion System Configuration::
* Control Functions::
* Bindable Commands::
* Completion Functions::
* Completion Directories::


File: zsh.info,  Node: Initialization,  Next: Completion System Configuration,  Up: Completion System

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
section 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
immediately.  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
mentioned 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
installation 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
directory 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
initialization.

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
necessary.  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
parameter must contain the directory in which they are stored.  If zsh
was properly installed on your system, then fpath/FPATH automatically
contains 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
subdirectories 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 completing
     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 functions that can
     perform many different completions.  It is implemented by setting
     the parameter $service when calling the function; 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 completions
     respectively.  Hence -P may be used to specify default actions.

     The option -N is used after a list following -p or -P; it
     specifies that remaining words no longer define patterns.  It is
     possible to toggle between the three options as many times as
     necessary.

#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 completion, namely
     complete-word, delete-char-or-list, expand-or-complete,
     expand-or-complete-prefix, list-choices, menu-complete,
     menu-expand-or-complete, or reverse-menu-complete.  If the
     zsh/complist module is loaded (see *Note The zsh/complist
     Module::) 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 argument
     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 flag is 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.

Note also that the functions for the completion system assume that the
KSH_AUTOLOAD option is not set.  They cannot be loaded if it is set.
To avoid having to unset KSH_AUTOLOAD, you can instead use one or more
zwc file(s) that have been created with the command zcompile -z to load
the functions for the completion system; see *Note Shell Builtin
Commands::.  This forces the functions to be autoloaded the way zsh
normally loads functions.

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 function
     called may set the _compskip parameter to one of various values:
     all: no further completion is attempted; a string containing 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
information.  (Internally, this is handled by the functions for each
context calling the function _dispatch.)  The extra information is
added separated by commas.

For the -redirect- context, the extra information is in the form
`-redirect-,OP,COMMAND', where OP is the redirection operator and
COMMAND 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
associative 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
functions 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
function 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
handled 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=SERVICE'.
     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 example, to
     complete files ending in `.h' as arguments to the command 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 identical,
     switching between definitions of patterns tried initially,
     patterns tried finally, and normal commands and contexts.

     The parameter $_compskip may be set by any function defined for a
     pattern context.  If it is set to a value containing the substring
     `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-complete,
     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 beginning
     with an underscore.

     Wherever applicable, the -a option makes the FUNCTION
     autoloadable, equivalent to autoload -U FUNCTION.

The function compdef can be used to associate existing completion
functions 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.

