mirror of
git://git.code.sf.net/p/zsh/code
synced 2024-11-19 13:33:52 +01:00
b9c58a73ac
are to use the -A "-*" and -S options to _arguments (13863)
1070 lines
46 KiB
Plaintext
1070 lines
46 KiB
Plaintext
texinode(Completion Widgets)(Completion System)(Zsh Line Editor)(Top)
|
|
chapter(Completion Widgets)
|
|
cindex(completion, widgets)
|
|
cindex(completion, programmable)
|
|
cindex(completion, controlling)
|
|
sect(Description)
|
|
The shell's programmable completion mechanism can be manipulated in two
|
|
ways; here the low-level features supporting the newer, function-based
|
|
mechanism are defined. A complete set of shell functions based on these
|
|
features is described in
|
|
ifzman(zmanref(zshcompsys))\
|
|
ifnzman(the next chapter, noderef(Completion System)),
|
|
and users with no interest in adding to that system (or, potentially,
|
|
writing their own --- see dictionary entry for `hubris') should skip this
|
|
section. The older system based on the tt(compctl) builtin command is
|
|
described in
|
|
ifzman(zmanref(zshcompctl))\
|
|
ifnzman(the chapter noderef(Completion Using compctl)).
|
|
|
|
Completion widgets are defined by the tt(-C) option to the tt(zle)
|
|
builtin command provided by the tt(zsh/zle) module (see
|
|
ifzman(zmanref(zshzle))\
|
|
ifnzman(noderef(The zsh/zle Module))\
|
|
). For example,
|
|
|
|
example(zle -C complete expand-or-complete completer)
|
|
|
|
defines a widget named `tt(complete)'. The second argument is the name
|
|
of any of the builtin widgets that handle completions:
|
|
tt(complete-word), tt(expand-or-complete),
|
|
tt(expand-or-complete-prefix), tt(menu-complete),
|
|
tt(menu-expand-or-complete), tt(reverse-menu-complete),
|
|
tt(list-choices), or tt(delete-char-or-list). Note that this will still
|
|
work even if the widget in question has been re-bound.
|
|
|
|
When this newly defined widget is bound to a key
|
|
using the tt(bindkey) builtin command defined in the tt(zsh/zle) module
|
|
(\
|
|
ifzman(see zmanref(zshzle))\
|
|
ifnzman(noderef(Zsh Line Editor))\
|
|
), typing that key will call the shell function `tt(completer)'. This
|
|
function is responsible for generating the possible matches using the
|
|
builtins described below. As with other ZLE widgets, the function is
|
|
called with its standard input closed.
|
|
|
|
Once the function returns, the completion code takes over control again
|
|
and treats the matches in the same manner as the specified builtin
|
|
widget, in this case tt(expand-or-complete).
|
|
|
|
startmenu()
|
|
menu(Special Parameters)
|
|
menu(Builtin Commands)
|
|
menu(Condition Codes)
|
|
menu(Matching Control)
|
|
menu(Completion Widget Example)
|
|
endmenu()
|
|
|
|
texinode(Special Parameters)(Builtin Commands)()(Completion Widgets)
|
|
sect(Special Parameters)
|
|
|
|
Inside completion widgets, and any functions called from them, some
|
|
parameters have special meaning; outside these functions they are not
|
|
special to the shell in any way. These parameters are used to pass
|
|
information between the completion code and the completion widget. Some of
|
|
the builtin commands and the condition codes use or change the current
|
|
values of these parameters. Any existing values will be hidden during
|
|
execution of completion widgets; except for tt(compstate), the parameters
|
|
are reset on each function exit (including nested function calls from
|
|
within the completion widget) to the values they had when the function was
|
|
entered.
|
|
|
|
startitem()
|
|
vindex(CURRENT)
|
|
item(tt(CURRENT))(
|
|
This is the number of the current word, i.e. the word the cursor is
|
|
currently on in the tt(words) array. Note that this value is only
|
|
correct if the tt(ksharrays) option is not set.
|
|
)
|
|
vindex(IPREFIX)
|
|
item(tt(IPREFIX))(
|
|
Initially this will be set to the empty string. This parameter functions
|
|
like tt(PREFIX); it contains a string which precedes the one in tt(PREFIX)
|
|
and is not considered part of the list of matches. Typically, a string is
|
|
transferred from the beginning of tt(PREFIX) to the end of tt(IPREFIX), for
|
|
example:
|
|
|
|
example(IPREFIX=${PREFIX%%\=*}=
|
|
PREFIX=${PREFIX#*=})
|
|
|
|
causes the part of the prefix up to and including the first equal sign not
|
|
to be treated as part of a matched string. This can be done automatically
|
|
by the tt(compset) builtin, see below.
|
|
)
|
|
vindex(ISUFFIX)
|
|
item(tt(ISUFFIX))(
|
|
As tt(IPREFIX), but for a suffix that should not be considered part
|
|
of the matches; note that the tt(ISUFFIX) string follows the tt(SUFFIX)
|
|
string.
|
|
)
|
|
vindex(PREFIX)
|
|
item(tt(PREFIX))(
|
|
Initially this will be set to the part of the current word from the
|
|
beginning of the word up to the position of the cursor; it may be altered
|
|
to give a common prefix for all matches.
|
|
)
|
|
vindex(QIPREFIX)
|
|
item(tt(QIPREFIX))(
|
|
This parameter is read-only and contains the quoted string up to the
|
|
word being completed. E.g. when completing `tt("foo)', this parameter
|
|
contains the double quote. If the tt(-q) option of tt(compset) is used
|
|
(see below), and the original string was `tt("foo bar)' with the
|
|
cursor on the `tt(bar)', this parameter contains `tt("foo )'.
|
|
)
|
|
vindex(QISUFFIX)
|
|
item(tt(QISUFFIX))(
|
|
Like tt(QIPREFIX), but containing the suffix.
|
|
)
|
|
vindex(SUFFIX)
|
|
item(tt(SUFFIX))(
|
|
Initially this will be set to the part of the current word from the
|
|
cursor position to the end; it may be altered to give a common suffix for
|
|
all matches. It is most useful when the option tt(COMPLETE_IN_WORD) is
|
|
set, as otherwise the whole word on the command line is treated as a
|
|
prefix.
|
|
)
|
|
vindex(compstate)
|
|
cindex(completion widgets, examining and setting state in)
|
|
item(tt(compstate))(
|
|
This is an associative array with various keys and values that the
|
|
completion code uses to exchange information with the completion widget.
|
|
The keys are:
|
|
|
|
startitem()
|
|
vindex(all_quotes, compstate)
|
|
item(tt(all_quotes))(
|
|
The tt(-q) option of the tt(compset) builtin command (see below)
|
|
allows a quoted string to be broken into separate words; if the cursor is
|
|
on one of those words, that word will be completed, possibly invoking
|
|
`tt(compset -q)' recursively. With this key it is possible to test the
|
|
types of quoted strings which are currently broken into parts in this
|
|
fashion. Its value contains one character for each quoting level. The
|
|
characters are a single quote or a double quote for strings quoted with
|
|
these characters and a backslash for strings not starting with a quote
|
|
character. The first character in the value always corresponds to the
|
|
innermost quoting level.
|
|
)
|
|
vindex(context, compstate)
|
|
item(tt(context))(
|
|
This will be set by the completion code to the overall context
|
|
in which completion is attempted. Possible values are:
|
|
|
|
startitem()
|
|
item(tt(array_value))(
|
|
when completing inside the value of an array parameter assignment; in
|
|
this case the tt(words) array contains the words inside the parentheses.
|
|
)
|
|
item(tt(brace_parameter))(
|
|
when completing the name of a parameter in a parameter expansion beginning
|
|
with tt(${).
|
|
)
|
|
item(tt(command))(
|
|
when completing for a normal command (either in command position or for
|
|
an argument of the command).
|
|
)
|
|
item(tt(condition))(
|
|
when completing inside a `tt([[)...tt(]])' conditional expression; in
|
|
this case the tt(words) array contains only the words inside the
|
|
conditional expression.
|
|
)
|
|
item(tt(math))(
|
|
when completing in a mathematical environment such as a
|
|
`tt(LPAR()LPAR())...tt(RPAR()RPAR())' construct.
|
|
)
|
|
item(tt(parameter))(
|
|
when completing the name of a parameter in a parameter expansion beginning
|
|
with tt($) but not tt(${).
|
|
)
|
|
item(tt(redirect))(
|
|
when completing after a redirection operator.
|
|
)
|
|
item(tt(subscript))(
|
|
when completing inside a parameter subscript.
|
|
)
|
|
item(tt(value))(
|
|
when completing the value of a parameter assignment.
|
|
)
|
|
enditem()
|
|
)
|
|
vindex(exact, compstate)
|
|
item(tt(exact))(
|
|
Controls the behaviour when the tt(REC_EXACT) option is set. It will be
|
|
set to tt(accept) if an exact match would be accepted, and will be unset
|
|
otherwise.
|
|
|
|
If it was set when at least one match equal to the string on the line
|
|
was generated, the match is accepted.
|
|
)
|
|
vindex(exact_string, compstate)
|
|
item(tt(exact_string))(
|
|
The string of an exact match if one was found, otherwise unset.
|
|
)
|
|
vindex(ignored, compstate)
|
|
item(tt(ignored))(
|
|
The number of words that were ignored because they matched one of the
|
|
patterns given with the tt(-F) option to the tt(compadd) builtin
|
|
command.
|
|
)
|
|
vindex(insert, compstate)
|
|
item(tt(insert))(
|
|
This controls the manner in which a match is inserted into the command
|
|
line. On entry to the widget function, if it is unset the command line is
|
|
not to be changed; if set to tt(unambiguous), any prefix common to all
|
|
matches is to be inserted; if set to tt(automenu-unambiguous), the
|
|
common prefix is to be inserted and the next invocation of the
|
|
completion code may start menu completion (due to the tt(AUTO_MENU)
|
|
option being set); if set to tt(menu) or tt(automenu) menu completion
|
|
will be started for the matches currently generated (in the
|
|
latter case this will happen because the tt(AUTO_MENU) is set). The
|
|
value may also contain the string `tt(tab)' when the completion code
|
|
would normally not really do completion, but only insert the TAB
|
|
character.
|
|
|
|
On exit it may be set to any of the values above (where setting it to
|
|
the empty string is the same as unsetting it), or to a number, in which
|
|
case the match whose number is given will be inserted into the command line.
|
|
Negative numbers count backward from the last match (with `tt(-1)'
|
|
selecting the last match) and out-of-range values are wrapped
|
|
around, so that a value of zero selects the last match and a value
|
|
one more than the maximum selects the first. Unless the value of this
|
|
key ends in a space, the match is inserted as in a menu completion,
|
|
i.e. without automatically appending a space.
|
|
|
|
Both tt(menu) and tt(automenu) may also specify the the number of the
|
|
match to insert, given after a colon. For example, `tt(menu:2)' says
|
|
to start menu completion, beginning with the second match.
|
|
|
|
Note that a value containing the substring `tt(tab)' makes the
|
|
matches generated be ignored and only the TAB be inserted.
|
|
|
|
Finally, it may also be set to tt(all), which makes all matches
|
|
generated be inserted into the line.
|
|
)
|
|
vindex(insert_positions, compstate)
|
|
item(tt(insert_positions))(
|
|
When the completion system inserts an unambiguous string into the
|
|
line, there may be multiple places where characters are missing or
|
|
where the character inserted differs from at least one match. The
|
|
value of this key contains a colon separated list of all these
|
|
positions, as indexes into the command line.
|
|
)
|
|
vindex(last_prompt, compstate)
|
|
item(tt(last_prompt))(
|
|
If this is set to a non-empty string for every match added, the
|
|
completion code will move the cursor back to the previous prompt after
|
|
the list of completions has been displayed. Initially this is set or
|
|
unset according to the tt(ALWAYS_LAST_PROMPT) option.
|
|
)
|
|
vindex(list, compstate)
|
|
item(tt(list))(
|
|
This controls whether or how the list of matches will be displayed. If it
|
|
is unset or empty they will never be listed; if its value begins with
|
|
tt(list), they will always be listed; if it begins with tt(autolist)
|
|
or tt(ambiguous), they will be listed when the tt(AUTO_LIST) or
|
|
tt(LIST_AMBIGUOUS) options respectively would normally cause them to
|
|
be.
|
|
|
|
If the substring tt(force) appears in the value, this makes the
|
|
list be shown even if there is only one match. Normally, the list
|
|
would be shown only if there are at least two matches.
|
|
|
|
The value contains the substring tt(packed) if the tt(LIST_PACKED)
|
|
option is set. If this substring is given for all matches added to a
|
|
group, this group will show the tt(LIST_PACKED) behavior. The same is
|
|
done for the tt(LIST_ROWS_FIRST) option with the substring tt(rows).
|
|
|
|
Finally, if the value contains the string tt(explanations), only the
|
|
explanation strings, if any, will be listed and if it contains
|
|
tt(messages), only the messages (added with the tt(-x) option of
|
|
tt(compadd)) will be listed. If it contains both tt(explanations) and
|
|
tt(messages) both kinds of explanation strings will be listed. It
|
|
will be set appropriately on entry to a completion widget and may be
|
|
changed there.
|
|
)
|
|
vindex(list_lines, compstate)
|
|
item(tt(list_lines))(
|
|
This gives the number of lines that are needed to display the full
|
|
list of completions. Note that to calculate the total number of lines
|
|
to display you need to add the number of lines needed for the command
|
|
line to this value, this is available as the value of the tt(BUFFERLINES)
|
|
special parameter.
|
|
)
|
|
vindex(list_max, compstate)
|
|
item(tt(list_max))(
|
|
Initially this is set to the value of the tt(LISTMAX) parameter.
|
|
It may be set to any other value; when the widget exits this value
|
|
will be used in the same way as the value of tt(LISTMAX).
|
|
)
|
|
vindex(nmatches, compstate)
|
|
item(tt(nmatches))(
|
|
The number of matches generated and accepted by the completion code so
|
|
far.
|
|
)
|
|
vindex(old_insert, compstate)
|
|
item(tt(old_insert))(
|
|
On entry to the widget this will be set to the number of the match of
|
|
an old list of completions that is currently inserted into the command
|
|
line. If no match has been inserted, this is unset.
|
|
|
|
As with tt(old_list), the value of this key will only be used if it is the
|
|
string tt(keep). If it was set to this value by the widget and there was an
|
|
old match inserted into the command line, this match will be kept and if
|
|
the value of the tt(insert) key specifies that another match should be
|
|
inserted, this will be inserted after the old one.
|
|
)
|
|
vindex(old_list, compstate)
|
|
item(tt(old_list))(
|
|
This is set to tt(yes) if there is still a valid list of completions
|
|
from a previous completion at the time the widget is invoked. This will
|
|
usually be the case if and only if the previous editing operation was a
|
|
completion widget or one of the builtin completion functions. If there is a
|
|
valid list and it is also currently shown on the screen, the value of this
|
|
key is tt(shown).
|
|
|
|
After the widget has exited the value of this key is only used if it
|
|
was set to tt(keep). In this case the completion code will continue
|
|
to use this old list. If the widget generated new matches, they will
|
|
not be used.
|
|
)
|
|
vindex(parameter, compstate)
|
|
item(tt(parameter))(
|
|
The name of the parameter when completing in a subscript or in the
|
|
value of a parameter assignment.
|
|
)
|
|
vindex(pattern_insert, compstate)
|
|
item(tt(pattern_insert))(
|
|
Normally this is set to tt(menu), which specifies that menu completion will
|
|
be used whenever a set of matches was generated using pattern matching. If
|
|
it is set to any other non-empty string by the user and menu completion is
|
|
not selected by other option settings, the code will instead insert any
|
|
common prefix for the generated matches as with normal completion.
|
|
)
|
|
vindex(pattern_match, compstate)
|
|
item(tt(pattern_match))(
|
|
Locally controls the behaviour given by the tt(GLOB_COMPLETE) option.
|
|
Initially it is set to `tt(*)' if and only if the option is set.
|
|
The completion widget may set it to this value, to an empty string
|
|
(which has the same effect as unsetting it), or to any
|
|
other non-empty string. If it is non-empty, unquoted metacharacters on the
|
|
command line will be treated as patterns; if it is `tt(*)', then
|
|
additionally a wildcard `tt(*)' is assumed at the cursor position; if
|
|
it is empty or unset, metacharacters will be treated literally.
|
|
|
|
Note that the matcher specifications given to the tt(compadd) builtin
|
|
command are not used if this is set to a non-empty string.
|
|
)
|
|
vindex(quote, compstate)
|
|
item(tt(quote))(
|
|
When completing inside quotes, this contains the quotation character
|
|
(i.e. either a single quote, a double quote, or a backtick). Otherwise it
|
|
is unset.
|
|
)
|
|
vindex(quoting, compstate)
|
|
item(tt(quoting))(
|
|
When completing inside single quotes, this is set to the string
|
|
tt(single); inside double quotes, the string
|
|
tt(double); inside backticks, the string tt(backtick).
|
|
Otherwise it is unset.
|
|
)
|
|
vindex(redirect, compstate)
|
|
item(tt(redirect))(
|
|
The redirection operator when completing in a redirection position,
|
|
i.e. one of tt(<), tt(>), etc.
|
|
)
|
|
vindex(restore, compstate)
|
|
item(tt(restore))(
|
|
This is set to tt(auto) before a function is entered, which forces the
|
|
special parameters mentioned above (tt(words), tt(CURRENT), tt(PREFIX),
|
|
tt(IPREFIX), tt(SUFFIX), and tt(ISUFFIX)) to be restored to their
|
|
previous values when the function exits. If a function unsets it or
|
|
sets it to any other string, they will not be restored.
|
|
)
|
|
vindex(to_end, compstate)
|
|
item(tt(to_end))(
|
|
Specifies the occasions on which the cursor is moved to the end of a string
|
|
when a match is inserted. On entry to a widget function, it may be
|
|
tt(single) if this will happen when a single unambiguous match was inserted
|
|
or tt(match) if it will happen any time a match is inserted (for example,
|
|
by menu completion; this is likely to be the effect of the tt(ALWAYS_TO_END)
|
|
option).
|
|
|
|
On exit, it may be set to tt(single) as above. It may also be set to
|
|
tt(always), or to the empty string or unset; in those cases the cursor will
|
|
be moved to the end of the string always or never respectively. Any
|
|
other string is treated as tt(match).
|
|
)
|
|
vindex(unambiguous, compstate)
|
|
item(tt(unambiguous))(
|
|
This key is read-only and will always be set to the common (unambiguous)
|
|
prefix the completion code has generated for all matches added so far.
|
|
)
|
|
vindex(unambiguous_cursor, compstate)
|
|
item(tt(unambiguous_cursor))(
|
|
This gives the position the cursor would be placed at if the
|
|
common prefix in the tt(unambiguous) key were inserted, relative to
|
|
the value of that key. The cursor would be placed before the character
|
|
whose index is given by this key.
|
|
)
|
|
vindex(unambiguous_positions, compstate)
|
|
item(tt(unambiguous_positions))(
|
|
This contains all positions where characters in the unambiguous string
|
|
are missing or where the character inserted differs from at least one
|
|
of the matches. The positions are given as indexes into the string
|
|
given by the value of the tt(unambiguous) key.
|
|
)
|
|
vindex(vared, compstate)
|
|
item(tt(vared))(
|
|
If completion is called while editing a line using the tt(vared)
|
|
builtin, the value of this key is set to the name of the parameter
|
|
given as an argument to tt(vared). This key is only set while a tt(vared)
|
|
command is active.
|
|
)
|
|
enditem()
|
|
)
|
|
vindex(words)
|
|
item(tt(words))(
|
|
This array contains the words present on the command line currently being
|
|
edited.
|
|
)
|
|
enditem()
|
|
|
|
texinode(Builtin Commands)(Condition Codes)(Special Parameters)(Completion Widgets)
|
|
sect(Builtin Commands)
|
|
startitem()
|
|
findex(compadd)
|
|
cindex(completion widgets, adding specified matches)
|
|
xitem(tt(compadd) [ tt(-akqQfenUl12C) ] [ tt(-F) var(array) ])
|
|
xitem([ tt(-P) var(prefix) ] [ tt(-S) var(suffix) ])
|
|
xitem([ tt(-p) var(hidden-prefix) ] [ tt(-s) var(hidden-suffix) ])
|
|
xitem([ tt(-i) var(ignored-prefix) ] [ tt(-I) var(ignored-suffix) ])
|
|
xitem([ tt(-W) var(file-prefix) ] [ tt(-d) var(array) ])
|
|
xitem([ tt(-J) var(name) ] [ tt(-V) var(name) ] [ tt(-X) var(explanation) ] [ tt(-x) var(message) ])
|
|
xitem([ tt(-r) var(remove-chars) ] [ tt(-R) var(remove-func) ])
|
|
xitem([ tt(-D) var(array) ] [ tt(-O) var(array) ] [ tt(-A) var(array) ])
|
|
item([ tt(-M) var(match-spec) ] [ tt(--) ] [ var(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:
|
|
|
|
indent(var(<ipre><apre><hpre><word><hsuf><asuf><isuf>))
|
|
|
|
The first field
|
|
is an ignored prefix taken from the command line, the contents of the
|
|
tt(IPREFIX) parameter plus the string given with the tt(-i)
|
|
option. With the tt(-U) option, only the string from the tt(-i)
|
|
option is used. The field var(<apre>) is an optional prefix string
|
|
given with the tt(-P) option. The var(<hpre>) field is a string
|
|
that is considered part of the match but that should not be shown when
|
|
listing completions, given with the tt(-p) option; for example,
|
|
functions that do filename generation might specify
|
|
a common path prefix this way. var(<word>) is the part of the match that
|
|
should appear in the list of completions, i.e. one of the var(words) given
|
|
at the end of the tt(compadd) command line. The suffixes var(<hsuf>),
|
|
var(<asuf>) and var(<isuf>) correspond to the prefixes var(<hpre>),
|
|
var(<apre>) and var(<ipre>) and are given by the options tt(-s), tt(-S) and
|
|
tt(-I), respectively.
|
|
|
|
The supported flags are:
|
|
|
|
startitem()
|
|
item(tt(-P) var(prefix))(
|
|
This gives a string to be inserted before the given var(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.
|
|
)
|
|
item(tt(-S) var(suffix))(
|
|
Like tt(-P), but gives a string to be inserted after the match.
|
|
)
|
|
item(tt(-p) var(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
|
|
tt(-U) option is given, this string must be matched as part of the string
|
|
on the command line.
|
|
)
|
|
item(tt(-s) var(hidden-suffix))(
|
|
Like `tt(-p)', but gives a string to insert after the match.
|
|
)
|
|
item(tt(-i) var(ignored-prefix))(
|
|
This gives a string to insert into the command line just before any
|
|
string given with the `tt(-P)' option. Without `tt(-P)' the string is
|
|
inserted before the string given with `tt(-p)' or directly before the
|
|
match.
|
|
)
|
|
item(tt(-I) var(ignored-suffix))(
|
|
Like tt(-i), but gives an ignored suffix.
|
|
)
|
|
item(tt(-a))(
|
|
With this flag the var(words) are taken as names of arrays and the
|
|
possible matches are their values. If only some elements of the
|
|
arrays are needed, the var(words) may also contain subscripts, as in
|
|
`tt(foo[2,-1])'.
|
|
)
|
|
item(tt(-k))(
|
|
With this flag the var(words) are taken as names of associative arrays
|
|
and the possible matches are their keys. As for tt(-a), the
|
|
var(words) may also contain subscripts, as in `tt(foo[(R)*bar*])'.
|
|
)
|
|
item(tt(-d) var(array))(
|
|
This adds per-match display strings. The var(array) should contain one
|
|
element per var(word) given. The completion code will then display the
|
|
first element instead of the first var(word), and so on. The
|
|
var(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 var(words), the leftover
|
|
var(words) will be displayed unchanged and if there are more display
|
|
strings than var(words), the leftover display strings will be silently
|
|
ignored.
|
|
)
|
|
item(tt(-l))(
|
|
This option only has an effect if used together with the tt(-d)
|
|
option. If it is given, the display strings are listed one per line,
|
|
not arrayed in columns.
|
|
)
|
|
item(tt(-J) var(name))(
|
|
Gives the name of the group of matches the words should be stored in.
|
|
)
|
|
item(tt(-V) var(name))(
|
|
Like tt(-J) but naming a unsorted group. These are in a different name
|
|
space than groups created with the tt(-J) flag.
|
|
)
|
|
item(tt(-1))(
|
|
If given together with the tt(-V) option, makes
|
|
only consecutive duplicates in the group be removed. If combined with
|
|
the tt(-J) option, this has no visible effect. Note that groups
|
|
with and without this flag are in different name spaces.
|
|
)
|
|
item(tt(-2))(
|
|
If given together with the tt(-J) or tt(-V) option, makes all
|
|
duplicates be kept. Again, groups with and without this flag are in
|
|
different name spaces.
|
|
)
|
|
item(tt(-X) var(explanation))(
|
|
The var(explanation) string will be printed with the list of matches,
|
|
above the group currently selected.
|
|
)
|
|
item(tt(-x) var(message))(
|
|
Like tt(-X), but the var(message) will be printed even if there are no
|
|
matches in the group.
|
|
)
|
|
item(tt(-q))(
|
|
The suffix given with tt(-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.
|
|
)
|
|
item(tt(-r) var(remove-chars))(
|
|
This is a more versatile form of the tt(-q) option.
|
|
The suffix given with tt(-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
|
|
var(remove-chars). This string is parsed as a characters class and
|
|
understands the backslash sequences used by the tt(print) command. For
|
|
example, `tt(-r "a-z\t")' removes the suffix if the next character typed
|
|
inserts a lowercase character or a TAB, and `tt(-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: `tt(\-)' stands for
|
|
all characters that insert nothing. Thus `tt(-S "=" -q)' is the same
|
|
as `tt(-S "=" -r "= \t\n\-")'.
|
|
)
|
|
item(tt(-R) var(remove-func))(
|
|
This is another form of the tt(-r) option. When a suffix
|
|
has been inserted and the completion accepted, the function
|
|
var(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
|
|
ifzman(zmanref(zshzle))\
|
|
ifnzman(noderef(Zsh Line Editor))\
|
|
) to analyse and modify the command line.
|
|
)
|
|
item(tt(-f))(
|
|
If this flag is given, all of the matches built from var(words) are
|
|
marked as being the names of files. They are not required to be actual
|
|
filenames, but if they are, and the option tt(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.
|
|
)
|
|
item(tt(-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 tt(AUTO_PARAM_SLASH) and tt(AUTO_PARAM_KEYS) options be used for
|
|
the matches.
|
|
)
|
|
item(tt(-W) var(file-prefix))(
|
|
This string is a pathname that will be
|
|
prepended to each of the matches formed by the given var(words) together
|
|
with any prefix specified by the tt(-p) option to form a complete filename
|
|
for testing. Hence it is only useful if combined with the tt(-f) flag, as
|
|
the tests will not otherwise be performed.
|
|
)
|
|
item(tt(-F) var(array))(
|
|
Specifies an array containing patterns. Words matching one of these
|
|
patterns are ignored, i.e. not considered to be possible matches.
|
|
|
|
The var(array) may be the name of an array parameter or a list of
|
|
literal patterns enclosed in parentheses and quoted, as in `tt(-F "(*?.o
|
|
*?.h)")'. If the name of an array is given, the elements of the array are
|
|
taken as the patterns.
|
|
)
|
|
item(tt(-Q))(
|
|
This flag instructs the completion
|
|
code not to quote any metacharacters in the words when inserting them
|
|
into the command line.
|
|
)
|
|
item(tt(-M) var(match-spec))(
|
|
This gives local match specifications as described below in
|
|
noderef(Matching Control). This option may be given more than once. In
|
|
this case all var(match-spec)s given are concatenated with spaces
|
|
between them to form the specification string to use.
|
|
Note that they will only be used if the tt(-U) option is not given.
|
|
)
|
|
item(tt(-n))(
|
|
Specifies that the words added are to be used as possible
|
|
matches, but are not to appear in the completion listing.
|
|
)
|
|
item(tt(-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.
|
|
)
|
|
item(tt(-O) var(array))(
|
|
If this option is given, the var(words) are em(not) added to the set of
|
|
possible completions. Instead, matching is done as usual and all of the
|
|
var(words) given as arguments that match the string on the command line
|
|
will be stored in the array parameter whose name is given as var(array).
|
|
)
|
|
item(tt(-A) var(array))(
|
|
As the tt(-O) option, except that instead of those of the var(words) which
|
|
match being stored in var(array), the strings generated internally by the
|
|
completion code are stored. For example,
|
|
with a matching specification of `tt(-M "L:|no=")', the string `tt(nof)'
|
|
on the command line and the string `tt(foo)' as one of the var(words), this
|
|
option stores the string `tt(nofoo)' in the array, whereas the tt(-O)
|
|
option stores the `tt(foo)' originally given.
|
|
)
|
|
item(tt(-D) var(array))(
|
|
As with tt(-O), the var(words) are not added to the set of possible
|
|
completions. Instead, the completion code tests whether each var(word)
|
|
in turn matches what is on the line. If the var(n)'th var(word) does not
|
|
match, the var(n)'th element of the var(array) is removed. Elements
|
|
for which the corresponding var(word) is matched are retained.
|
|
)
|
|
item(tt(-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 tt(-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.
|
|
)
|
|
xitem(tt(-))
|
|
item(tt(-)tt(-))(
|
|
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.
|
|
)
|
|
enditem()
|
|
|
|
Except for the tt(-M) flag, if any of these flags is given more than
|
|
once, the first one (and its argument) will be used.
|
|
)
|
|
findex(compset)
|
|
cindex(completion widgets, modifying special parameters)
|
|
xitem(tt(compset -p) var(number))
|
|
xitem(tt(compset -P) [ var(number) ] var(pattern))
|
|
xitem(tt(compset -s) var(number))
|
|
xitem(tt(compset -S) [ var(number) ] var(pattern))
|
|
xitem(tt(compset -n) var(begin) [ var(end) ])
|
|
xitem(tt(compset -N) var(beg-pat) [ var(end-pat) ])
|
|
item(tt(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:
|
|
|
|
startitem()
|
|
item(tt(-p) var(number))(
|
|
If the contents of the tt(PREFIX) parameter is longer than var(number)
|
|
characters, the first var(number) characters are removed from it and
|
|
appended to the contents of the tt(IPREFIX) parameter.
|
|
)
|
|
item(tt(-P) [ var(number) ] var(pattern))(
|
|
If the value of the tt(PREFIX) parameter begins with anything that
|
|
matches the var(pattern), the matched portion is removed from
|
|
tt(PREFIX) and appended to tt(IPREFIX).
|
|
|
|
Without the optional var(number), the longest match is taken, but
|
|
if var(number) is given, anything up to the var(number)'th match is
|
|
moved. If the var(number) is negative, the var(number)'th longest
|
|
match is moved. For example, if tt(PREFIX) contains the string
|
|
`tt(a=b=c)', then tt(compset -P '*\=') will move the string `tt(a=b=)'
|
|
into the tt(IPREFIX) parameter, but tt(compset -P 1 '*\=') will move only
|
|
the string `tt(a=)'.
|
|
)
|
|
item(tt(-s) var(number))(
|
|
As tt(-p), but transfer the last var(number) characters from the
|
|
value of tt(SUFFIX) to the front of the value of tt(ISUFFIX).
|
|
)
|
|
item(tt(-S) [ var(number) ] var(pattern))(
|
|
As tt(-P), but match the last portion of tt(SUFFIX) and transfer the
|
|
matched portion to the front of the value of tt(ISUFFIX).
|
|
)
|
|
item(tt(-n) var(begin) [ var(end) ])(
|
|
If the current word position as specified by the parameter tt(CURRENT)
|
|
is greater than or equal to var(begin), anything up to the
|
|
var(begin)'th word is removed from the tt(words) array and the value
|
|
of the parameter tt(CURRENT) is decremented by var(begin).
|
|
|
|
If the optional var(end) is given, the modification is done only if
|
|
the current word position is also less than or equal to var(end). In
|
|
this case, the words from position var(end) onwards are also removed from
|
|
the tt(words) array.
|
|
|
|
Both var(begin) and var(end) may be negative to count backwards
|
|
from the last element of the tt(words) array.
|
|
)
|
|
item(tt(-N) var(beg-pat) [ var(end-pat) ])(
|
|
If one of the elements of the tt(words) array before the one at the
|
|
index given by the value of the parameter tt(CURRENT) matches the
|
|
pattern var(beg-pat), all elements up to and including the matching one are
|
|
removed from the tt(words) array and the value of tt(CURRENT) is changed to
|
|
point to the same word in the changed array.
|
|
|
|
If the optional pattern var(end-pat) is also given, and there is an
|
|
element in the tt(words) array matching this pattern, the parameters
|
|
are modified only if the index of this word is higher than the one
|
|
given by the tt(CURRENT) parameter (so that the matching word has
|
|
to be after the cursor). In this case, the words starting with the one
|
|
matching tt(end-pat) are also removed from the tt(words)
|
|
array. If tt(words) contains no word matching var(end-pat), the
|
|
testing and modification is performed as if it were not given.
|
|
)
|
|
item(tt(-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 tt(words) array, and tt(CURRENT),
|
|
tt(PREFIX), tt(SUFFIX), tt(QIPREFIX), and tt(QISUFFIX) are modified to
|
|
reflect the word part that is completed.
|
|
)
|
|
enditem()
|
|
|
|
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:
|
|
|
|
example(if compset -P '*\='; then ...)
|
|
|
|
This forces anything up to and including the last equal sign to be
|
|
ignored by the completion code.
|
|
)
|
|
item(tt(compcall) [ tt(-TD) ])(
|
|
This allows the use of completions defined with the tt(compctl) builtin
|
|
from within completion widgets. The list of matches will be generated as
|
|
if one of the non-widget completion function (tt(complete-word), etc.)
|
|
had been called, except that only tt(compctl)s given for specific commands
|
|
are used. To force the code to try completions defined with the tt(-T)
|
|
option of tt(compctl) and/or the default completion (whether defined by
|
|
tt(compctl -D) or the builtin default) in the appropriate places, the
|
|
tt(-T) and/or tt(-D) flags can be passed to tt(compcall).
|
|
|
|
The return value can be used to test if a matching tt(compctl)
|
|
definition was found. It is non-zero if a tt(compctl) was found and
|
|
zero otherwise.
|
|
|
|
Note that this builtin is defined by the tt(zsh/compctl) module.
|
|
)
|
|
enditem()
|
|
|
|
texinode(Condition Codes)(Matching Control)(Builtin Commands)(Completion Widgets)
|
|
sect(Condition Codes)
|
|
cindex(completion widgets, condition codes)
|
|
|
|
The following additional condition codes for use within the tt([[ ... ]])
|
|
construct are available in completion widgets. These work on the special
|
|
parameters. All of these tests can also be performed by the tt(compset)
|
|
builtin, but in the case of the condition codes the contents of the special
|
|
parameters are not modified.
|
|
|
|
startitem()
|
|
item(tt(-prefix) [ var(number) ] var(pattern))(
|
|
true if the test for the tt(-P) option of tt(compset) would succeed.
|
|
)
|
|
item(tt(-suffix) [ var(number) ] var(pattern))(
|
|
true if the test for the tt(-S) option of tt(compset) would succeed.
|
|
)
|
|
item(tt(-after) var(beg-pat))(
|
|
true if the test of the tt(-N) option with only the var(beg-pat) given
|
|
would succeed.
|
|
)
|
|
item(tt(-between) var(beg-pat end-pat))(
|
|
true if the test for the tt(-N) option with both patterns would succeed.
|
|
)
|
|
enditem()
|
|
|
|
texinode(Matching Control)(Completion Widget Example)(Condition Codes)(Completion Widgets)
|
|
sect(Matching Control)
|
|
|
|
It is possible by use of the
|
|
tt(-M) option of the tt(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 tt(GLOB_COMPLETE) option is set or the tt(pattern_match) of the
|
|
tt(compstate) special association is set to a non-empty string.
|
|
|
|
The var(match-spec) given as the argument to the tt(-M) option (see
|
|
ifzman(`Builtin Commands' above)\
|
|
ifnzman(noderef(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 var(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.
|
|
|
|
startitem()
|
|
xitem(tt(m:)var(lpat)tt(=)var(tpat))
|
|
item(tt(M:)var(lpat)tt(=)var(tpat))(
|
|
Here, var(lpat) is a pattern that matches on the command line,
|
|
corresponding to var(tpat) which matches in the trial completion.
|
|
)
|
|
xitem(tt(l:)var(lanchor)tt(|)var(lpat)tt(=)var(tpat))
|
|
xitem(tt(L:)var(lanchor)tt(|)var(lpat)tt(=)var(tpat))
|
|
xitem(tt(l:)var(lanchor)tt(||)var(ranchor)tt(=)var(tpat))
|
|
xitem(tt(L:)var(lanchor)tt(||)var(ranchor)tt(=)var(tpat))
|
|
xitem(tt(b:)var(lpat)tt(=)var(tpat))
|
|
item(tt(B:)var(lpat)tt(=)var(tpat))(
|
|
These letters are for patterns that are anchored by another pattern on
|
|
the left side. Matching for var(lpat) and var(tpat) is as for tt(m) and
|
|
tt(M), but the pattern var(lpat) matched on the command line must be
|
|
preceded by the pattern var(lanchor). The var(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 var(lpat) is given but a var(ranchor) is, this matches the gap
|
|
between substrings matched by var(lanchor) and var(ranchor). Unlike
|
|
var(lanchor), the var(ranchor) only needs to match the trial
|
|
completion string.
|
|
|
|
The tt(b) and tt(B) forms are similar to tt(l) and tt(L) with an empty
|
|
anchor, but need to match only the beginning of the trial completion
|
|
or the word on the command line, respectively.
|
|
)
|
|
xitem(tt(r:)var(lpat)tt(|)var(ranchor)tt(=)var(tpat))
|
|
xitem(tt(R:)var(lpat)tt(|)var(ranchor)tt(=)var(tpat))
|
|
xitem(tt(r:)var(lanchor)tt(||)var(ranchor)tt(=)var(tpat))
|
|
xitem(tt(R:)var(lanchor)tt(||)var(ranchor)tt(=)var(tpat))
|
|
xitem(tt(e:)var(lpat)tt(=)var(tpat))
|
|
item(tt(E:)var(lpat)tt(=)var(tpat))(
|
|
As tt(l), tt(L), tt(b) and tt(B), with the difference that the command
|
|
line and trial completion patterns are anchored on the right side.
|
|
Here an empty var(ranchor) and the tt(e) and tt(E) forms force the
|
|
match to the end of the trial completion or command line string.
|
|
)
|
|
enditem()
|
|
|
|
Each var(lpat), var(tpat) or var(anchor) is either an empty string or
|
|
consists of a sequence of literal characters (which may be quoted with a
|
|
backslash), question marks, character classes, and correspondence
|
|
classes; ordinary shell patterns are not used. Literal characters match
|
|
only themselves, question marks match any character, and character
|
|
classes are formed as for globbing and match any character in the given
|
|
set.
|
|
|
|
Correspondence classes are defined like character classes, but with two
|
|
differences: they are delimited by a pair of braces, and negated classes
|
|
are not allowed, so the characters tt(!) and tt(^) have no special
|
|
meaning directly after the opening brace. They indicate that a range of
|
|
characters on the line match a range of characters in the trial
|
|
completion, but (unlike ordinary character classes) paired according to
|
|
the corresponding position in the sequence. For example, to make any
|
|
lowercase letter on the line match the corresponding uppercase letter in
|
|
the trial completion, you can use `tt(m:{a-z}={A-Z})'. More than one
|
|
pair of classes can occur, in which case the first class before the
|
|
tt(=) corresponds to the first after it, and so on. If one side has
|
|
more such classes than the other side, the superfluous classes behave
|
|
like normal character classes. In anchor patterns correspondence classes
|
|
also behave like normal character classes.
|
|
|
|
The pattern var(tpat) may also be one or two stars, `tt(*)' or
|
|
`tt(**)'. This means that the pattern on the command line can match
|
|
any number of characters in the trial completion. In this case the
|
|
pattern must be anchored (on either side); in the case of a single
|
|
star, the var(anchor) then determines how much of the trial completion
|
|
is to be included --- only the characters up to the next appearance of
|
|
the anchor will be matched. With two stars, substrings matched by the
|
|
anchor can be matched, too.
|
|
|
|
Examples:
|
|
|
|
The keys of the tt(options) association defined by the tt(parameter)
|
|
module are the option names in all-lowercase form, without
|
|
underscores, and without the optional tt(no) at the beginning even
|
|
though the builtins tt(setopt) and tt(unsetopt) understand option names
|
|
with uppercase letters, underscores, and the optional tt(no). The
|
|
following alters the matching rules so that the prefix tt(no) and any
|
|
underscore are ignored when trying to match the trial completions
|
|
generated and uppercase letters on the line match the corresponding
|
|
lowercase letters in the words:
|
|
|
|
example(compadd -M 'L:|[nN][oO]= M:_= M:{A-Z}={a-z}' - \
|
|
${(k)options} )
|
|
|
|
The first part says that the pattern `tt([nN][oO])' at the beginning
|
|
(the empty anchor before the pipe symbol) of the string on the
|
|
line matches the empty string in the list of words generated by
|
|
completion, so it will be ignored if present. The second part does the
|
|
same for an underscore anywhere in the command line string, and the
|
|
third part uses correspondence classes so that any
|
|
uppercase letter on the line matches the corresponding lowercase
|
|
letter in the word. The use of the uppercase forms of the
|
|
specification characters (tt(L) and tt(M)) guarantees that what has
|
|
already been typed on the command line (in particular the prefix
|
|
tt(no)) will not be deleted.
|
|
|
|
Note that the use of tt(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 `tt(_NO_f)' would not be
|
|
completed to `tt(_NO_foo)', nor would `tt(NONO_f)' be completed to
|
|
`tt(NONO_foo)' because of the leading underscore or the second
|
|
`tt(NO)' on the line which makes the pattern fail even though they are
|
|
otherwise ignored. To fix this, one would use `tt(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 var(match-spec)s.
|
|
|
|
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:
|
|
|
|
example(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:
|
|
|
|
example(compadd -M 'm:{a-zA-Z}={A-Za-z}' ... )
|
|
|
|
A nice example for the use of tt(*) patterns is partial word
|
|
completion. Sometimes you would like to make strings like `tt(c.s.u)'
|
|
complete to strings like `tt(comp.source.unix)', i.e. the word on the
|
|
command line consists of multiple parts, separated by a dot in this
|
|
example, where each part should be completed separately --- note,
|
|
however, that the case where each part of the word, i.e. `tt(comp)',
|
|
`tt(source)' and `tt(unix)' in this example, is to be completed 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:
|
|
|
|
example(compadd -M 'r:|.=* r:|=*' \
|
|
- comp.sources.unix comp.sources.misc ...)
|
|
|
|
The first specification says that var(lpat) is the empty string, while
|
|
var(anchor) is a dot; var(tpat) is tt(*), so this can match anything
|
|
except for the `tt(.)' from the anchor in
|
|
the trial completion word. So in `tt(c.s.u)', the matcher sees `tt(c)',
|
|
followed by the empty string, followed by the anchor `tt(.)', and
|
|
likewise for the second dot, and replaces the empty strings before the
|
|
anchors, giving `tt(c)[tt(omp)]tt(.s)[tt(ources)]tt(.u)[tt(nix)]', where
|
|
the last part of the completion is just as normal.
|
|
|
|
With the pattern shown above, the string `tt(c.u)' could not be
|
|
completed to `tt(comp.sources.unix)' because the single star means
|
|
that no dot (matched by the anchor) can be skipped. By using two stars
|
|
as in `tt(r:|.=**)', however, `tt(c.u)' could be completed to
|
|
`tt(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
|
|
tt(COMPLETE_IN_WORD) is set. In this case the completion code would
|
|
normally try to match trial completions that end with the string as
|
|
typed so far, i.e. it will only insert new characters at the cursor
|
|
position rather then at the end. However in our example we would like
|
|
the code to recognise matches which contain extra characters after the
|
|
string on the line (the `tt(nix)' in the example). Hence we say that the
|
|
empty string at the end of the string on the line matches any characters
|
|
at the end of the trial completion.
|
|
|
|
More generally, the specification
|
|
|
|
example(compadd -M 'r:|[.,_-]=* r:|=*' ... )
|
|
|
|
allows one to complete words with abbreviations before any of the
|
|
characters in the square brackets. For example, to
|
|
complete tt(veryverylongfile.c) rather than tt(veryverylongheader.h)
|
|
with the above in effect, you can just type tt(very.c) before attempting
|
|
completion.
|
|
|
|
The 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 `tt(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:
|
|
|
|
example(compadd -M 'r:|[A-Z0-9]=* r:|=*' LikeTHIS FooHoo 5foo123 5bar234)
|
|
|
|
But with this, the string `tt(H)' would neither complete to `tt(FooHoo)'
|
|
nor to `tt(LikeTHIS)' because in each case there is an uppercase
|
|
letter before the `tt(H)' and that is matched by the anchor. Likewise,
|
|
a `tt(2)' would not be completed. In both cases this could be changed
|
|
by using `tt(r:|[A-Z0-9]=**)', but then `tt(H)' completes to both
|
|
`tt(LikeTHIS)' and `tt(FooHoo)' and a `tt(2)' matches the other
|
|
strings because characters can be inserted before every uppercase
|
|
letter and digit. To avoid this one would use:
|
|
|
|
example(compadd -M 'r:[^A-Z0-9]||[A-Z0-9]=** r:|=*' \
|
|
LikeTHIS FooHoo foo123 bar234)
|
|
|
|
By using these two anchors, a `tt(H)' matches only uppercase `tt(H)'s that
|
|
are immediately preceded by something matching the left anchor
|
|
`tt([^A-Z0-9])'. The effect is, of course, that `tt(H)' matches only
|
|
the string `tt(FooHoo)', a `tt(2)' matches only `tt(bar234)' and so on.
|
|
|
|
When using the completion system (see
|
|
ifzman(zmanref(zshcompsys))\
|
|
ifnzman(noderef(Completion System))\
|
|
), users can define match specifications that are to be used for
|
|
specific contexts by using the tt(matcher) and tt(matcher-list)
|
|
styles. The values for the latter will be used everywhere.
|
|
|
|
texinode(Completion Widget Example)()(Matching Control)(Completion Widgets)
|
|
sect(Completion Widget Example)
|
|
cindex(completion widgets, example)
|
|
|
|
The first step is to define the widget:
|
|
|
|
example(zle -C complete complete-word complete-files)
|
|
|
|
Then the widget can be bound to a key using the tt(bindkey) builtin
|
|
command:
|
|
|
|
example(bindkey '^X\t' complete)
|
|
|
|
After that the shell function tt(complete-files) will be invoked
|
|
after typing control-X and TAB. The function should then generate the
|
|
matches, e.g.:
|
|
|
|
example(complete-files LPAR()RPAR() { compadd - * })
|
|
|
|
This function will complete files in the current directory matching the
|
|
current word.
|