texinode(Completion System)()(Zsh Modules)(Top) chapter(Completion System) cindex(completion, system) cindex(completion, programmable) cindex(completion, controlling) sect(Description) This describes the shell code for the new completion system. It consists of two scripts and a few other files that define shell functions. The shell functions which implement completion behaviour and which may be bound to keystrokes, are referred to as `widgets'. All are contained in the following subdirectories of the tt(Completion) directory of the main distribution directory. startitem() item(tt(Core))( The core scripts and functions. You will certainly need these, though will probably not need to alter them. The contents of this directory is described in more detail below. ) item(tt(Base))( Other functions you will almost certainly want if you are going to use any of the standard completion functions. You may want to edit some of these files. ) item(tt(Builtins))( Functions for completing arguments of shell builtin commands. ) item(tt(User))( Functions for completing arguments of external commands and suites of commands. They may need modifying for your system. ) item(tt(Commands))( Functions which implement special types of completion to be bound to keystrokes rather than called by context. ) enditem() You should decide which files you will be using and copy them to a directory (or multiple directories) of your own which should appear in your tt($fpath) variable so that the functions can be autoloaded. startmenu() menu(Initialisation) menu(Control Functions) menu(Completion Functions) endmenu() texinode(Initialisation)(Control Functions)()(Completion System) sect(Initialisation) To initialise the system, the script tt(compinit) should be sourced with `tt(source )var()tt(/compinit)' or `tt(. )var()tt(/compinit)'. This will define a few utility functions, arrange for all the necessary shell functions to be autoloaded, and will then re-bind all keys that do completion to use the new system. subsect(Arguments) To speed up the running of tt(compinit), it can be made to produce a dumped configuration which will be read in on future invocations. The easiest way to do this is by adding the option tt(-d) whenever tt(compinit) is sourced. In this case the dumped file will have the same name as the sourced file, but with tt(.dump) appended to the end; alternatively, an explicit file name can be given following the tt(-d). On the next call to tt(compinit -d), the dumped file will be read instead. If the number of completion files changes, tt(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 tt(#compdef) funcion (as described below) change, it is easiest to delete the dump file by hand so that the next time tt(compinit) will re-create it. The dumping is actually done by another script, tt(compdump), but you will only need to source this yourself if you change the configuration (e.g. using tt(compdef)) and then want to dump the new one. The name of the old dumped file will be remembered for this. subsect(Autoloaded files) The convention for autoloaded functions used in completion is that they start with an underscore; as already mentioned, the tt(fpath/FPATH) parameter must contain the directory in which they are stored. When tt(compinit) is sourced, it searches all such files accessible via tt(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: startitem() item(tt(#compdef) var(names...))( The file will be made autoloadable and the function defined in it will be called when completing var(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 tt(-)var(context)tt(-) described below for the tt(_complete) function. ) item(tt(#compdef -p) var(pattern))( The file will be made autoloadable and the function defined in it will be called when completing for a command whose name matches the given var(pattern) (a standard globbing pattern). Note that only one var(pattern) may be given. ) item(tt(#compdef -k) var(style key-sequences...))( This can be used bind special completion functions to the var(key-sequences). It creates a widget behaving like the builtin widget var(style), which must be one of those that perform completion, namely tt(complete-word), tt(delete-char-or-list), tt(expand-or-complete), tt(expand-or-complete-prefix), tt(list-choices), tt(menu-complete), tt(menu-expand-or-complete), or tt(reverse-menu-complete). The widget is then bound to all the var(key-sequences) given, if any: when one of the var(key-sequences) is typed, the function in the file will be invoked to generate the matches. The widget created has the same name as the file and can also be bound to other keys using tt(bindkey) as usual. ) item(tt(#autoload))( This is used for files defining utility function that are not to be called directly as completion functions but should be loaded automatically when invoked. Typically they are to be called from within one of the completion functions. ) enditem() Note that the tt(#) is part of the tag name and no white space is allowed after it. The tt(#compdef) tags use the tt(compdef) function defined below; the main difference is that the name of the function is supplied implicitly. subsect(Functions) The tt(compinit) file defines the following functions, which may also be called directly by the user. startitem() xitem(tt(compdef) [ tt(-an) ] var(function names...)) xitem(tt(compdef -d) var(names...)) xitem(tt(compdef -p) [ tt(-a) ] var(function pattern)) item(tt(compdef -k) [ tt(-a) ] var(function style key-sequences...))( The first form tells the completion system to call the given var(function) when completing for the contexts or commands whose var(names) are given: this is like the tt(#compdef) tag. If the tt(-n) option is given, any existing completion behaviour for particular contexts or commands will not be altered. These definitions can be deleted by giving the tt(-d) option as in the second form. The third form is similar to the first, but var(function) will be called for all commands whose name matches the var(pattern); this is like the tt(#compdef -p) function tag. The fourth form defines a widget with the same name as the var(function) which will be called for each of the var(key-sequences); this is like the tt(#compdef -k) tag. The function should generate the completions needed and will otherwise behave like the builtin widget whose name is given as the var(style) argument. The widgets usable for this are: tt(complete-word), tt(delete-char-or-list), tt(expand-or-complete), tt(expand-or-complete-prefix), tt(list-choices), tt(menu-complete), tt(menu-expand-or-complete), and tt(reverse-menu-complete). In each of the forms supporting it the tt(-a) option makes the var(function) autoloadable (exactly equivalent to tt(autoload )var(function)). ) xitem(tt(compconf) var(definitions...)) xitem(tt(compconf)) item(tt(compconf) [ tt(-l) ] var(keys...))( Several aspects of the completion system can be configured by the user. The configuration values are stored under the keys described below in the associative array `tt(compconfig)'. After sourcing tt(compinit), configuration values can either be set directly as in `tt(compconfig[completer]=_complete)' or by calling this utility function. Each var(definition) may be either a simple `var(key)', which sets this key in the tt(compconfig) array to an empty string, or of the form `var(key=value)' which stores the `var(value)' under key `var(key)'. Since the completion system also uses the array for internal purposes, you should not set all values at once by doing `tt(compconfig=(...))'. In the second form (without arguments), this function lists all keys and their values. If given the tt(-l) option as its first argument, as in the last form, the other arguments are taken as names of keys and the values of these keys are printed one per line. ) enditem() texinode(Control Functions)(Completion Functions)(Initialisation)(Completion System) sect(Control Functions) The initialisation script tt(compinit) re-binds all the keys which perform completion to newly created widgets that all call the supplied widget function tt(_main_complete). This function acts as a wrapper calling the so-called `completer' functions that generate matches. If tt(_main_complete) is called with arguments, these are taken as the names of completer functions to be called in the order given. If no arguments are given, the set of functions to try is taken from the colon-separated list in the configuration key tt(completer). For example, to use normal completion and correction if that doesn't generate any matches: indent( nofill(tt(compconf completer=_complete:_correct)) ) after sourcing tt(compinit). The default value for this configuration key set up in tt(compinit) is `tt(_complete)', i.e. normally only ordinary completion is tried. The tt(_main_complete) function uses the return value of the completer functions to decide if other completers should be called. If the return value is zero, no other completers are tried and the tt(_main_complete) function returns. The following completer functions are contained in the distribution (users may write their own): startitem() item(tt(_complete))( This completer generates all possible completions in a context-sensitive manner, i.e. using the tt(compdef) function explained above and the current settings of all special parameters. To complete arguments of commands, tt(_complete) uses the utility function tt(_normal), which is in turn responsible for finding the particular function; it is described below. Various contexts of the form tt(-)var(context)tt(-), as mentioned above for the tt(#compdef) tag, are handled specially. These are: startitem() item(tt(-equal-))( for completion after an equal sign, other than one occurring in a shell-variable assignment. ) item(tt(-tilde-))( for completion after a tilde (`tt(~)') character, but before a slash. ) item(tt(-redirect-))( for completion after a redirection operator. ) item(tt(-math-))( for completion inside mathematical contexts, such as `tt(LPAR()LPAR())...tt(RPAR()RPAR())'. ) item(tt(-subscript-))( for completion inside subscripts. ) item(tt(-value-))( for completion on the right hand side of an assignment. ) item(tt(-array-value-))( for completion on the right hand side of an array-assignment (`tt(foo=LPAR()...RPAR())'). ) item(tt(-condition-))( for completion inside conditions (`tt([[...]])'). ) item(tt(-parameter-))( for completing the name of a parameter expansion (`tt($...)'). ) item(tt(-brace-parameter-))( for completing the name of a parameter expansion within braces (`tt(${...})'). ) item(tt(-first-))( for adding completions before any other other completion functions are tried (similar to the `tt(-T)' flag of tt(compctl)); if this function sets the tt(_compskip) parameter to any value, the completion system will not call any other function to generate matches. ) item(tt(-default-))( for generating completions when no special completion function is used (similar to the `tt(-D)' option of tt(compctl)). ) item(tt(-command-))( for completing in a command position (as with the `tt(-C)' option of tt(compctl)). ) enditem() Default implementations are supplied for each of these contexts, in most cases named after the context itself (e.g. completion for the `tt(-tilde-)' context is done by the function named `tt(_tilde)'). ) item(tt(_approximate))( This completer function uses the tt(_complete) completer to generate a list of strings for the context the cursor is currently in, allowing you to specify a maximum number of errors: see the description of approximate matching in ifzman(\ zmanref(zshexpn) )\ ifnzman(\ noderef(Filename Generation) )\ for how errors are counted. The resulting list of corrected and completed strings is then presented to the user. The intended use of this completer function is to try after the normal tt(_complete) completer by setting: indent( nofill(tt(compconf completer=_complete:_approximate)) ) This will give correcting completion if and only if normal completion doesn't yield any possible completions. When corrected completions are found, the completer will normally start menucompletion allowing you to cycle through these strings. The exact behavior of this completer can be changed by using the following configuration keys: startitem() item(tt(approximate_accept))( This should be set to the number of errors the correction code should accept. The completer will try to generate completions by first allowing one error, then two errors, and so on, until either a match was found or the maximum number of errors given by this key has been reached. If the value for this key contains a lower- or upper-case `tt(n)', the completer function will take any numeric argument as the maximum number of errors allowed. For example, with indent( nofill(tt(compconf approximate_accept=2n)) ) two errors will be allowed if no numeric argument is given. However, with a numeric argument of six (as in `tt(ESC-6 TAB)'), up to six errors are accepted. Hence with a value of `tt(0n)', no correcting completion will be attempted unless a numeric argument is given. If the value contains `tt(n)' or `tt(N)' and a exclamation mark (`tt(!)'), tt(_approximate) will var(not) try to generate corrected completions when given a numeric argument, so in this case the number given should be greater than zero. For example, `tt(2n!)' specifies that correcting completion with two errors will usually be performed, but if a numeric argument is given, correcting completion will not be performed. ) item(tt(approximate_original))( This key is used to specify whether the original string on which correcting completion was attempted is to be included in the list of possible corrections. If it is set to any non-empty string, the original string will be offered when cycling through the completions. Normally it will appear as the first string, so that the command line does not change immediately; consecutive completion attempts will cycle through the corrected strings. If the value for this key contains the substring `tt(last)', the original string will be the last one in the list, so that it appears just before wrapping around to the first corrected string again. Also, if the value contains the substring `tt(always)', the original string will always be included; normally it is included only if more than one possible correction was generated. ) item(tt(approximate_prompt))( This can be set to a string to be displayed on top of the corrected strings generated when cycling through them. This string may contain the control sequences `tt(%n)', `tt(%B)', etc. known from the `tt(-X)' option of tt(compctl). Also, the sequence `tt(%e)' will be replaced by the number of errors accepted to generate the corrected strings. ) item(tt(approximate_insert))( If this is set to a string starting with `tt(unambig)', the code will try to insert a usable unambiguous string in the command line instead of always cycling through the corrected strings. If such a unambiguous string could be found, the original string is not used, independent of the setting of tt(approximate_original). If no sensible string could be found, one can cycle through the corrected strings as usual. ) enditem() If any of these keys is not set, but the the same key with the prefix `tt(correct)' instead of `tt(approximate)' is set, that value will be used. The forms beginning with `tt(correct)' are also used by the tt(_correct) completer function. The keys with the `tt(approximate)' prefix have no default values, but tt(compinit) defines default values for tt(correct_accept) (which is set to `tt(2n)'), and tt(correct_prompt). ) item(tt(_correct))( Generate corrections (but not completions) for the current word; this is similar to spell-checking. This calls tt(_approximate), but only the configuration parameters beginning tt(correct_) are used. For example, with: indent(tt( nofill(compconf completer=_complete:_correct:_approximate) nofill(compconf correct_accept='2n!' approximate_accept=3n)) ) correction will accept up to two errors. If a numeric argument is given, correction will not be performed, but correcting completion will be, and will accept as many errors as given by the numeric argument. Without a numeric argument, first correction and then correcting completion will be tried, with the first one accepting two errors and the second one accepting three errors. This completer function is intended to be used without the tt(_approximate) completer or, as in the example, just before it. Using it after the tt(_approximate) completer is useless since tt(_approximate) will at least generate the corrected strings generated by the tt(_correct) completer -- and probably more. ) item(tt(_match))( This completer is intended to be used after the tt(_complete) completer. It allows one to give patterns on the command line and to complete all strings metching these patterns from the set of possible completions for the context the cursor is in, without having to set the tt(GLOB_COMPLETE) option. Normally this will be done by taking the pattern from the line, inserting a `tt(*)' at the cursor position and comparing the resulting pattern with the possible completions generated. However, if the configuration key tt(match_original) has a value of `tt(only)', no `tt(*)' will be inserted. If tt(match_original) has any other non-empty string as its value, this completer will first try to generate matches without, then with a `tt(*)' inserted at the cursor position. ) item(tt(_expand))( This completer function does not really do completion, but instead checks if the word on the command line is eligible for expansion and, if it is, gives detailed control over how this expansion is done. When using this, one should not use the tt(expand-or-complete) widget, but instead use tt(complete-word), as otherwise tt(expand-or-complete) will expand the string on the line before the completion widget is called. Also, this completer should be called before the tt(_complete) completer function. Control over how the expanded string will be treated is possible with the following configuration keys: startitem() item(tt(expand_substitute))( If this is unset or set to the empty string, the code will first try to expand all substitutions in the string (such as `tt($LPAR()...RPAR())' and `tt(${...})'). If this is set to an non-empty string it should be an expression usable inside a `tt($((...)))' arithmetical expression. In this case, expansion of substitutions will be done if the expression evaluates to `tt(1)'. For example, with indent( nofill(tt(compconf expand_substitute='NUMERIC != 1')) ) substitution will be performed only if given an explicit numeric argument other than `tt(1)', as by typing `tt(ESC 2 TAB)'. ) item(tt(expand_glob))( If this is unset or set to an empty string, globbing will be attempted on the word resulting from substitution or the original string. The values accepted for this key are the same as for tt(expand_substitute). ) item(tt(expand_menu))( If this is unset or set to the empty string, the words resulting from expansion (if any) will simply be inserted in the command line, replacing the original string. However, if this key is set to a non-empty string, the user can cycle through the expansion as in menucompletion. Unless the value contains the substring `tt(only)', the user will still be offered all expansions at once as one of the strings to insert in the command line; normally, this possibility is offered first, but if the value contains the substring `tt(last)', it is offered last. Finally, if the value contains the substring `tt(sort)', the expansions will be sorted alphabetically, normally they are kept in the order the expansion produced them in. ) item(tt(expand_original))( If this is set to an non-empty string, the original string from the line will be included in the list of strings the user can cycle through as in a menucompletion. If the value contains the substring `tt(last)', the original string will appear as the last string, with other values it is inserted as the first one (so that the command line does not change immediately). ) item(tt(expand_prompt))( This may be set to a string that should be displayed before the possible expansions. This is passed to the `tt(-X)' option of tt(compadd) and thus may contain the control sequences `tt(%n)', `tt(%B)', etc. Also, the sequence `tt(%o)' in this string will be replaced by the original string. ) enditem() None of these configuration keys has a default value. ) item(tt(_list))( This completer allows one to delay the insertion of matches until completion is attempted a second time without the word on the line being changed. On the first attempt, only the list of matches will be shown. Configuration keys understood are: startitem() item(tt(list_condition))( If this key is unset or set to the empty string, the insertion of matches will be delayed unconditionally. If this value is set, it should be set to an expression usable inside a `tt($((...)))' arithmetical expression. In this case, delaying will be done if the expression evaluates to `tt(1)'. For example, with indent( nofill(tt(compconf list_condition='NUMERIC != 1')) ) delaying will be done only if given an explicit numeric argument other than `tt(1)'. ) item(tt(list_word))( To find out if listing should be performed on its own, the code normally compares the contents of the line with the contents the line had at the time of the last invocation. If this key is set to an non-empty string, comparison is done using only the current word. So if it is set, attempting completion on a word equal to the one when completion was called the last time will not delay the generation of matches. ) enditem() ) item(tt(_menu))( This completer is a simple example function implemented to show how menucompletion can be done in shell code. It should be used as the first completer and has the effect of making the code perform menucompletion. Note that this is independent of the setting of the tt(MENU_COMPLETE) option and does not work with the other menucompletion widgets such as tt(reverse-menu-complete), or tt(accept-and-menu-complete). ) enditem() texinode(Completion Functions)()(Control Functions)(Completion System) sect(Utility Functions) Descriptions follow for utility functions that may be useful when writing completion functions. Most of these reside in the tt(Core) subdirectory except where noted. Like the example functions for commands in the distribution, the utility functions generating matches all follow the convention of returning zero if they generated completions and non-zero if no matching completions could be added. startitem() item(tt(_compalso))( This function looks up the definitions for the context and command names given as arguments and calls the handler functions for them if there is a definition (given with the tt(compdef) function). For example, the function completing inside subscripts might use `tt(_compalso -math-)' to include the completions generated for mathematical environments. ) item(tt(_normal))( This function is used for normal command completion. If completion is attempted on the first word, command names are completed. Otherwise, the arguments are completed by calling the functions defined for this command, including those functions defined for patterns matching the command name. This function can also be called by other completion functions if they have to complete a range of words as a separate command. For example, the function to complete after the pre-command specifiers such as tt(nohup) removes the first word from the tt(words) array, decrements the tt(CURRENT) parameter, then calls this function. When calling a function defined for a pattern, this function also checks if the parameter tt(_compskip) is set. If it was set by the function called, no further completion functions are called. With this one can write a pattern completion function that keeps other functions from being tried simply by setting this parameter to any value. ) item(tt(_multi_parts))( This functions gets two arguments: a separator character and an array. As usual, the array may be either the name of an array parameter or a literal array in the form `tt(LPAR()foo bar)tt(RPAR())' (i.e. a list of words separated by white space in parentheses). With these arguments, this function will complete to strings from the array where the parts separated by the separator character are completed independently. For example, the tt(_tar) function from the distribution caches the pathnames from the tar file in an array and then calls this function to complete these names in the way normal filenames are completed by the tt(_path_files) function. Like other utility functions, this function accepts the `tt(-V)', `tt(-J)', and `tt(-X)' options with an argument and passes them to the tt(compadd) builtin. ) item(tt(_sep_parts))( This function gets as arguments alternating arrays and separators. The arrays specify completions for parts of strings to be separated by the separators. The arrays may be the names of array parameters or a quoted list of words in parentheses. For example, with the array `tt(hosts=(ftp news))' the call `tt(_sep_parts '(foo bar)' @ hosts)' will complete the string `tt(f)' to `tt(foo)' and the string `tt(b@n)' to `tt(bar@news)'. This function passes the `tt(-V)', `tt(-J)', and `tt(-X)' options and their arguments to the tt(compadd) builtin used to add the matches. ) item(tt(_path_files) and tt(_files))( The function tt(_path_files) is used throughout the shell code to complete filenames. The advantage over the builtin completion functions is that it allows completion of partial paths. For example, the string `tt(/u/i/s/sig)' may be completed to `tt(/usr/include/sys/signal.h)'. The options `tt(-/)', `tt(-f)', `tt(-g)', and `tt(-W)' are available as for the tt(compctl) and tt(compgen) builtins; tt(-f) is the default. Additionally, the `tt(-F)' option from the tt(compadd) builtin is supported, giving direct control over which filenames should be ignored as done by the tt(fignore) parameter in normal completion. The function tt(_files) calls tt(_path_files) with all the arguments it was passed and, if that generated no matches, call tt(_path_files) again without any tt(-g) or tt(-/) option, thus generating all filenames. These functions also accept the `tt(-J)', `tt(-V)', `tt(-X)', `tt(-P)', `tt(-S)', `tt(-q)', `tt(-r)', and `tt(-R)' options from the tt(compadd) builtin. Finally, the tt(_path_files) function supports one configuration key: tt(path_expand). If this is set to any non-empty string, the partially typed path from the line will be expanded as far as possible even if trailing pathname components can not be completed. ) item(tt(_parameters))( This should be used to complete parameter names if you need some of the extra options of tt(compadd). It first tries to complete only non-local parameters. All arguments are passed unchanged to the tt(compadd) builtin. ) item(tt(_options))( This can be used to complete option names. The difference to the `tt(-o)' option of tt(compgen) is that this function uses a matching specification that ignores a leading `tt(no)', ignores underscores and allows the user to type upper-case letters, making them match their lower-case counterparts. All arguments passed to this function are propagated unchanged to the tt(compgen) builtin. ) item(tt(_set_options) and tt(_unset_options))( These functions complete only set or unset options, with the same matching specification used in the tt(_options) function. Note that you need to uncomment a few lines in the tt(_main_complete) function for these functions to work properly. The lines in question are used to store the option settings in effect before the completion widget locally sets the options it needs. ) item(tt(_long_options))( This function resides in the tt(Base) subdirectory of the example completion system because it is not used by the core system. This function is used to complete long options for commands that support the `tt(--help)' option as, for example, most of the GNU commands do. For this it invokes the command from the line with the `tt(--help)' option and then parses the output to find possible option names. Note that this means that you should be careful to make sure that this function is not called for a command that does not support this option. For options that get an argument after a `tt(=)', the function also automatically tries to find out what should be completed as the argument. The possible completions for option-arguments can be described with the arguments to this function. This is done by giving pairs of patterns and actions as consecutive arguments. The actions specify what should be done to complete arguments of those options whose description match the pattern. The action may be a list of words in brackets or in parentheses, separated by spaces. A list in square brackets denotes possible values for an optional argument, a list in parentheses gives words to complete for mandatory arguments. If the action does not start with a square bracket or parenthesis, it should be the name of a command (probably with arguments) that should be invoked to complete after the equal sign. Example: indent( nofill(tt(_long_options '*\*' '(yes no)' \)) nofill(tt( '*=FILE*' '_files' \)) nofill(tt( '*=DIR*' '_files -/')) ) Here, `tt(yes)' and `tt(no)' will be completed as the argument of options whose description ends in a star, file names for options that contain the substring `tt(=FILE)' in the description, and paths for options whose description contains `tt(=DIR)'. In fact, the last two patterns are not needed since this function always completes files for option descriptions containing `tt(=FILE)' and paths for option descriptions that contain `tt(=DIR)' or `tt(=PATH)'. These builtin patterns can be overridden by patterns given as arguments, however. This function also accepts the `tt(-X)', `tt(-J)', and `tt(-V)' options which are passed unchanged to `tt(compadd)'. Finally, it accepts the option `tt(-t)'; if this is given, completion is only done on words starting with two hyphens. ) enditem()