| ZSHZLE(1) | General Commands Manual | ZSHZLE(1) |
zshzle - zsh command line editor
If the ZLE option is set (which it is by default in interactive shells) and the shell input is attached to the terminal, the user is able to edit command lines.
There are two display modes. The first, multiline mode, is the default. It only works if the TERM parameter is set to a valid terminal type that can move the cursor up. The second, single line mode, is used if TERM is invalid or incapable of moving the cursor up, or if the SINGLE_LINE_ZLE option is set. This mode is similar to ksh, and uses no termcap sequences. If TERM is "emacs", the ZLE option will be unset by default.
The parameters BAUD, COLUMNS, and LINES are also used by the line editor. See Parameters Used By The Shell in zshparam(1).
The parameter zle_highlight is also used by the line editor; see Character Highlighting below. Highlighting of special characters and the region between the cursor and the mark (as set with set-mark-command in Emacs mode, or by visual-mode in Vi mode) is enabled by default; consult this reference for more information. Irascible conservatives will wish to know that all highlighting may be disabled by the following setting:
zle_highlight=(none)
In many places, references are made to the numeric argument. This can by default be entered in emacs mode by holding the alt key and typing a number, or pressing escape before each digit, and in vi command mode by typing the number before entering a command. Generally the numeric argument causes the next command entered to be repeated the specified number of times, unless otherwise noted below; this is implemented by the digit-argument widget. See also the Arguments subsection of the Widgets section for some other ways the numeric argument can be modified.
A keymap in ZLE contains a set of bindings between key sequences and ZLE commands. The empty key sequence cannot be bound.
There can be any number of keymaps at any time, and each keymap has one or more names. If all of a keymap's names are deleted, it disappears. bindkey can be used to manipulate keymap names.
Initially, there are eight keymaps:
The `.safe' keymap is special. It can never be altered, and the name can never be removed. However, it can be linked to other names, which can be removed. In the future other special keymaps may be added; users should avoid using names beginning with `.' for their own keymaps.
In addition to these names, either `emacs' or `viins' is also linked to the name `main'. If one of the VISUAL or EDITOR environment variables contain the string `vi' when the shell starts up then it will be `viins', otherwise it will be `emacs'. bindkey's -e and -v options provide a convenient way to override this default choice.
When the editor starts up, it will select the `main' keymap. If that keymap doesn't exist, it will use `.safe' instead.
In the `.safe' keymap, each single key is bound to self-insert, except for ^J (line feed) and ^M (return) which are bound to accept-line. This is deliberately not pleasant to use; if you are using it, it means you deleted the main keymap, and you should put it back.
When ZLE is reading a command from the terminal, it may read a sequence that is bound to some command and is also a prefix of a longer bound string. In this case ZLE will wait a certain time to see if more characters are typed, and if not (or they don't match any longer string) it will execute the binding. This timeout is defined by the KEYTIMEOUT parameter; its default is 0.4 sec. There is no timeout if the prefix string is not itself bound to a command.
The key timeout is also applied when ZLE is reading the bytes from a multibyte character string when it is in the appropriate mode. (This requires that the shell was compiled with multibyte mode enabled; typically also the locale has characters with the UTF-8 encoding, although any multibyte encoding known to the operating system is supported.) If the second or a subsequent byte is not read within the timeout period, the shell acts as if ? were typed and resets the input state.
As well as ZLE commands, key sequences can be bound to other strings, by using `bindkey -s'. When such a sequence is read, the replacement string is pushed back as input, and the command reading process starts again using these fake keystrokes. This input can itself invoke further replacement strings, but in order to detect loops the process will be stopped if there are twenty such replacements without a real command being read.
A key sequence typed by the user can be turned into a command name for use in user-defined widgets with the read-command widget, described in the subsection `Miscellaneous' of the section `Standard Widgets' below.
While for normal editing a single keymap is used exclusively, in many modes a local keymap allows for some keys to be customised. For example, in an incremental search mode, a binding in the isearch keymap will override a binding in the main keymap but all keys that are not overridden can still be used.
If a key sequence is defined in a local keymap, it will hide a key sequence in the global keymap that is a prefix of that sequence. An example of this occurs with the binding of iw in viopp as this hides the binding of i in vicmd. However, a longer sequence in the global keymap that shares the same prefix can still apply so for example the binding of ^Xa in the global keymap will be unaffected by the binding of ^Xb in the local keymap.
The ZLE module contains three related builtin commands. The bindkey command manipulates keymaps and key bindings; the vared command invokes ZLE on the value of a shell parameter; and the zle command manipulates editing widgets and allows command line access to ZLE commands from within shell functions.
If a keymap selection is required and none of the options above are used, the `main' keymap is used. Some operations do not permit a keymap to be selected, namely:
If the -L option is also used, list in the form of bindkey commands to create or link the keymaps. `bindkey -lL main' shows which keymap is linked to `main', if any, and hence if the standard emacs or vi emulation is in effect. This option does not show the .safe keymap because it cannot be created in that fashion; however, neither is `bindkey -lL .safe' reported as an error, it simply outputs nothing.
To use a newly created keymap, it should be linked to main. Hence the sequence of commands to create and use a new keymap `mymap' initialized from the emacs keymap (which remains unchanged) is:
bindkey -N mymap emacs bindkey -A mymap main
Note that while `bindkey -A newmap main' will work when newmap is emacs or viins, it will not work for vicmd, as switching from vi insert to command mode becomes impossible.
The following operations act on the `main' keymap if no keymap selection option was given:
When -R is also used, interpret the in-strings as ranges.
When -p is also used, the in-strings specify prefixes. Any binding that has the given in-string as a prefix, not including the binding for the in-string itself, if any, will be removed. For example,
bindkey -rpM viins '^['
will remove all bindings in the vi-insert keymap beginning with an escape character (probably cursor keys), but leave the binding for the escape character itself (probably vi-cmd-mode). This is incompatible with the option -R.
Note that both in-string and out-string are subject to the same form of interpretation, as described below.
When the option -p is used, the in-string must be present. The listing shows all bindings which have the given key sequence as a prefix, not including any bindings for the key sequence itself.
When the -L option is used, the list is in the form of bindkey commands to create the key bindings.
When the -R option is used as noted above, a valid range consists of two characters, with an optional `-' between them. All characters between the two specified, inclusive, are bound as specified.
For either in-string or out-string, the following escape sequences are recognised:
In all other cases, `\' escapes the following character. Delete is written as `^?'. Note that `\M^?' and `^\M?' are not the same, and that (unlike emacs), the bindings `\M-X' and `\eX' are entirely distinct, although they are initialized to the same bindings by `bindkey -m'.
If an array or array slice is being edited, separator characters as defined in $IFS will be shown quoted with a backslash, as will backslashes themselves. Conversely, when the edited text is split into an array, a backslash quotes an immediately following separator character or backslash; no other special handling of backslashes, or any handling of quotes, is performed.
Individual elements of existing array or associative array parameters may be edited by using subscript syntax on name. New elements are created automatically, even without -c.
If the -p flag is given, the following string will be taken as the prompt to display at the left. If the -r flag is given, the following string gives the prompt to display at the right. If the -h flag is specified, the history can be accessed from ZLE. If the -e flag is given, typing ^D (Control-D) on an empty line causes vared to exit immediately with a non-zero return value.
The -M option gives a keymap to link to the main keymap during editing, and the -m option gives a keymap to link to the vicmd keymap during editing. For vi-style editing, this allows a pair of keymaps to override viins and vicmd. For emacs-style editing, only -M is normally needed but the -m option may still be used. On exit, the previous keymaps will be restored.
Vared calls the usual `zle-line-init' and `zle-line-finish' hooks before and after it takes control. Using the -i and -f options, it is possible to replace these with other custom widgets.
If `-t tty' is given, tty is the name of a terminal device to be used instead of the default /dev/tty. If tty does not refer to a terminal an error is reported.
With no options and no arguments, only the return status will be set. It is zero if ZLE is currently active and widgets could be invoked using this builtin command and non-zero otherwise. Note that even if non-zero status is returned, zle may still be active as part of the completion system; this does not allow direct calls to ZLE widgets.
Otherwise, which operation it performs depends on its options:
When combined with the -a option, all widget names are listed, including the builtin ones. In this case the -L option is ignored.
If at least one string is given, and -a is present or -L is not used, nothing will be printed. The return status will be zero if all strings are names of existing widgets and non-zero if at least one string is not a name of a defined widget. If -a is also present, all widget names are used for the comparison including builtin widgets, else only user-defined widgets are used.
If at least one string is present and the -L option is used, user-defined widgets matching any string are listed in the form of zle commands to create the widgets.
yank for indicating that the widget has yanked text into the buffer. If the widget is wrapping an existing internal widget, no further action is necessary, but if it has inserted the text manually, then it should also take care to set YANK_START and YANK_END correctly. yankbefore does the same but is used when the yanked text appears after the cursor.
kill for indicating that text has been killed into the cutbuffer. When repeatedly invoking a kill widget, text is appended to the cutbuffer instead of replacing it, but when wrapping such widgets, it is necessary to call `zle -f kill' to retain this effect.
vichange for indicating that the widget represents a vi change that can be repeated as a whole with `vi-repeat-change'. The flag should be set early in the function before inspecting the value of NUMERIC or invoking other widgets. This has no effect for a widget invoked from insert mode. If insert mode is active when the widget finishes, the change extends until next returning to command mode.
If the optional strings are given they are listed below the prompt in the same way as completion lists are printed. If no strings are given but the -c option is used such a list is cleared.
Note that immediately after returning from running widgets, the command line will be redisplayed and the strings displayed will be erased. Therefore, this option is only useful for widgets that do not exit immediately after using it.
This command can safely be called outside user defined widgets; if zle is active, the display will be refreshed, while if zle is not active, the command has no effect. In this case there will usually be no other arguments.
The status is zero if zle was active, else one.
As ZLE uses a stack, if this option is used repeatedly the last string pushed onto the stack will be processed first. However, the characters in each string will be processed in the order in which they appear in the string.
This keymap selection affects the interpretation of following keystrokes within this invocation of ZLE. Any following invocation (e.g., the next command line) will start as usual with the `main' keymap selected.
Installs handler (the name of a shell function) to handle input from file descriptor fd. Installing a handler for an fd which is already handled causes the existing handler to be replaced. Any number of handlers for any number of readable file descriptors may be installed. Note that zle makes no attempt to check whether this fd is actually readable when installing the handler. The user must make their own arrangements for handling the file descriptor when zle is not active.
When zle is attempting to read data, it will examine both the terminal and the list of handled fd's. If data becomes available on a handled fd, zle calls handler with the fd which is ready for reading as the first argument. Under normal circumstances this is the only argument, but if an error was detected, a second argument provides details: `hup' for a disconnect, `nval' for a closed or otherwise invalid descriptor, or `err' for any other condition. Systems that support only the `select' system call always use `err'.
If the option -w is also given, the handler is instead a line editor widget, typically a shell function made into a widget using `zle -N'. In that case handler can use all the facilities of zle to update the current editing line. Note, however, that as handling fd takes place at a low level changes to the display will not automatically appear; the widget should call `zle -R' to force redisplay. As of this writing, widget handlers only support a single argument and thus are never passed a string for error state, so widgets must be prepared to test the descriptor themselves.
If either type of handler produces output to the terminal, it should call `zle -I' before doing so (see below). Handlers should not attempt to read from the terminal.
If no handler is given, but an fd is present, any handler for that fd is removed. If there is none, an error message is printed and status 1 is returned.
If no arguments are given, or the -L option is supplied, a list of handlers is printed in a form which can be stored for later execution.
An fd (but not a handler) may optionally be given with the -L option; in this case, the function will list the handler if any, else silently return status 1.
Note that this feature should be used with care. Activity on one of the fd's which is not properly handled can cause the terminal to become unusable. Removing an fd handler from within a signal trap may cause unpredictable behavior.
Here is a simple example of using this feature. A connection to a remote TCP port is created using the ztcp command; see the description of the zsh/net/tcp module in zshmodules(1). Then a handler is installed which simply prints out any data which arrives on this connection. Note that `select' will indicate that the file descriptor needs handling if the remote side has closed the connection; we handle that by testing for a failed read.
if ztcp pwspc 2811; then
tcpfd=$REPLY
handler() {
zle -I
local line
if ! read -r line <&$1; then
# select marks this fd if we reach EOF,
# so handle this specially.
print "[Read on fd $1 failed, removing.]" >&2
zle -F $1
return 1
fi
print -r - $line
}
zle -F $tcpfd handler fi
TRAPUSR1() {
# Invalidate zle display
[[ -o zle ]] && zle -I
# Show output
print Hello
}
In general, the trap function may need to test whether zle is active before using this method (as shown in the example), since the zsh/zle module may not even be loaded; if it is not, the command can be skipped.
It is possible to call `zle -I' several times before control is returned to the editor; the display will only be invalidated the first time to minimise disruption.
Note that there are normally better ways of manipulating the display from within zle widgets; see, for example, `zle -R' above.
The returned status is zero if zle was invalidated, even though this may have been by a previous call to `zle -I' or by a system notification. To test if a zle widget may be called at this point, execute zle with no arguments and examine the return status.
`zle -T transformation func' specifies that the given transformation (see below) is effected by shell function func.
`zle -Tr transformation' removes the given transformation if it was present (it is not an error if none was).
`zle -TL' can be used to list all transformations currently in operation.
Currently the only transformation is tc. This is used instead of outputting termcap codes to the terminal. When the transformation is in operation the shell function is passed the termcap code that would be output as its first argument; if the operation required a numeric argument, that is passed as a second argument. The function should set the shell variable REPLY to the transformed termcap code. Typically this is used to produce some simply formatted version of the code and optional argument for debugging or testing. Note that this transformation is not applied to other non-printing characters such as carriage returns and newlines.
With the options -n and -N, the current numeric argument will be saved and then restored after the call to widget; `-n num' sets the numeric argument temporarily to num, while `-N' sets it to the default, i.e. as if there were none.
With the option -K, keymap will be used as the current keymap during the execution of the widget. The previous keymap will be restored when the widget exits.
Normally, calling a widget in this way does not set the special parameter WIDGET and related parameters, so that the environment appears as if the top-level widget called by the user were still active. With the option -w, WIDGET and related parameters are set to reflect the widget being executed by the zle call.
Normally, when widget returns the special parameter LASTWIDGET will point to it. This can be inhibited by passing the option -f nolast.
Any further arguments will be passed to the widget; note that as standard argument handling is performed, any general argument list should be preceded by --. If it is a shell function, these are passed down as positional parameters; for builtin widgets it is up to the widget in question what it does with them. Currently arguments are only handled by the incremental-search commands, the history-search-forward and -backward and the corresponding functions prefixed by vi-, and by universal-argument. No error is flagged if the command does not use the arguments, or only uses some of them.
The return status reflects the success or failure of the operation carried out by the widget, or if it is a user-defined widget the return status of the shell function.
A non-zero return status causes the shell to beep when the widget exits, unless the BEEP options was unset or the widget was called via the zle command. Thus if a user defined widget requires an immediate beep, it should call the beep widget directly.
All actions in the editor are performed by `widgets'. A widget's job is simply to perform some small action. The ZLE commands that key sequences in keymaps are bound to are in fact widgets. Widgets can be user-defined or built in.
The standard widgets built into ZLE are listed in the section `Standard Widgets' below. Other built-in widgets can be defined by other modules (see zshmodules(1)). Each built-in widget has two names: its normal canonical name, and the same name preceded by a `.'. The `.' name is special: it can't be rebound to a different widget. This makes the widget available even when its usual name has been redefined.
User-defined widgets are defined using `zle -N', and implemented as shell functions. When the widget is executed, the corresponding shell function is executed, and can perform editing (or other) actions. It is recommended that user-defined widgets should not have names starting with `.'.
User-defined widgets, being implemented as shell functions, can execute any normal shell command. They can also run other widgets (whether built-in or user-defined) using the zle builtin command. The standard input of the function is redirected from /dev/null to prevent external commands from unintentionally blocking ZLE by reading from the terminal, but read -k or read -q can be used to read characters. Finally, they can examine and edit the ZLE buffer being edited by reading and setting the special parameters described below.
These special parameters are always available in widget functions, but are not in any way special outside ZLE. If they have some normal value outside ZLE, that value is temporarily inaccessible, but will return when the widget function exits. These special parameters in fact have local scope, like parameters created in a function using local.
Inside completion widgets and traps called while ZLE is active, these parameters are available read-only.
Note that the parameters appear as local to any ZLE widget in which they appear. Hence if it is desired to override them this needs to be done within a nested function:
widget-function() {
# $WIDGET here refers to the special variable
# that is local inside widget-function
() {
# This anonymous nested function allows WIDGET
# to be used as a local variable. The -h
# removes the special status of the variable.
local -h WIDGET
}
}
All parameters are read-only.
The default size for the kill ring is eight, however the length may be changed by normal array operations. Any empty string in the kill ring is ignored by the yank-pop command, hence the size of the array effectively sets the maximum length of the kill ring, while the number of non-zero strings gives the current length, both as seen by the user at the command line.
Each string consists of the following whitespace-separated parts:
Plugins may use this to identify array elements they have added: for example, a plugin might set token to its (the plugin's) name and then use `region_highlight=( ${region_highlight:#*memo=token} )' in order to remove array elements it have added.
(This example uses the `${name:#pattern}' array-grepping syntax described in the section `Parameter Expansion' in zshexpn(1).)
For example,
region_highlight=("P0 20 bold memo=foobar")
specifies that the first twenty characters of the text including any predisplay string should be highlighted in bold.
Note that the effect of region_highlight is not saved and disappears as soon as the line is accepted.
Note that zsh 5.8 and older do not support the `memo=token' field and may misparse the third (highlight specification) field when a memo is given.
The final highlighting on the command line depends on both region_highlight and zle_highlight; see the section CHARACTER HIGHLIGHTING below for details.
All parameters are read-only.
A typical use of this variable in a widget function is as follows (note the additional function scope is required):
() {
local UNDO_LIMIT_NO=$UNDO_CHANGE_NO
# Perform some form of recursive edit.
}
YANK_ACTIVE is read-only.
ZLE_RECURSIVE is read-only.
Currently, the states shown are the insert mode as set by the overwrite-mode or vi-replace widgets and whether history commands will visit imported entries as controlled by the set-local-history widget. The string contains `insert' if characters to be inserted on the command line move existing characters to the right or `overwrite' if characters to be inserted overwrite existing characters. It contains `localhistory' if only local history commands will be visited or `globalhistory' if imported history commands will also be visited.
The substrings are sorted in alphabetical order so that if you want to test for two specific substrings in a future-proof way, you can do match by doing:
if [[ $ZLE_STATE == *globalhistory*insert* ]]; then ...; fi
There are a few user-defined widgets which are special to the shell. If they do not exist, no special action is taken. The environment provided is identical to that for any other editing widget.
zle-isearch-update() { zle -M "Line $HISTNO"; }
zle -N zle-isearch-update
Note the line output by `zle -M' is not deleted on exit from incremental search. This can be done from a zle-isearch-exit widget:
zle-isearch-exit() { zle -M ""; }
zle -N zle-isearch-exit
zle-line-init() { zle -K vicmd; }
zle -N zle-line-init
(The command inside the function sets the keymap directly; it is equivalent to zle vi-cmd-mode.)
The value $KEYMAP within the function reflects the new keymap. The old keymap is passed as the sole argument.
This can be used for detecting switches between the vi command (vicmd) and insert (usually main) keymaps.
The following is a list of all the standard widgets, and their default bindings in emacs mode, vi command mode and vi insert mode (the `emacs', `vicmd' and `viins' keymaps, respectively).
Note that cursor keys are bound to movement keys in all three keymaps; the shell assumes that the cursor keys send the key sequences reported by the terminal-handling library (termcap or terminfo). The key sequences shown in the list are those based on the VT100, common on many modern terminals, but in fact these are not necessarily bound. In the case of the viins keymap, the initial escape character of the sequences serves also to return to the vicmd keymap: whether this happens is determined by the KEYTIMEOUT parameter, see zshparam(1).
If called from a function by the zle command with arguments, the first argument is taken as the string for which to search, rather than the first word in the buffer.
A restricted set of editing functions is available in the mini-buffer. Keys are looked up in the special isearch keymap, and if not found there in the main keymap (note that by default the isearch keymap is empty). An interrupt signal, as defined by the stty setting, will stop the search and go back to the original line. An undefined key will have the same effect. Note that the following always perform the same task within incremental searches and cannot be replaced by user defined widgets, nor can the set of functions be extended. The supported functions are:
In addition, the modifications that were made while in vi insert mode are merged to form a single undo event.
Any character that is not bound to one of the above functions, or self-insert or self-insert-unmeta, will cause the mode to be exited. The character is then looked up and executed in the keymap in effect at that point.
When called from a widget function by the zle command, the incremental search commands can take a string argument. This will be treated as a string of keys, as for arguments to the bindkey command, and used as initial input for the command. Any characters in the string which are unused by the incremental search will be silently ignored. For example,
zle history-incremental-search-backward forceps
will search backwards for forceps, leaving the minibuffer containing the string `forceps'.
The prompt changes to indicate an invalid pattern; this may simply indicate the pattern is not yet complete.
Note that only non-overlapping matches are reported, so an expression with wildcards may return fewer matches on a line than are visible by inspection.
If called from a function by the zle command with arguments, the first argument is taken as the string for which to search, rather than the first word in the buffer.
A restricted set of editing functions is available in the mini-buffer. An interrupt signal, as defined by the stty setting, will stop the search. The functions available in the mini-buffer are: accept-line, backward-delete-char, vi-backward-delete-char, backward-kill-word, vi-backward-kill-word, clear-screen, redisplay, quoted-insert and vi-quoted-insert.
vi-cmd-mode is treated the same as accept-line, and magic-space is treated as a space. Any other character that is not bound to self-insert or self-insert-unmeta will beep and be ignored. If the function is called from vi command mode, the bindings of the current insert mode will be used.
If called from a function by the zle command with arguments, the first argument is taken as the string for which to search, rather than the first word in the buffer.
If called from a function by the zle command with arguments, the first argument is taken as the string for which to search, rather than the first word in the buffer.
When called from a shell function invoked from a user-defined widget, the command can take one to three arguments. The first argument specifies a history offset which applies to successive calls to this widget: if it is -1, the default behaviour is used, while if it is 1, successive calls will move forwards through the history. The value 0 can be used to indicate that the history line examined by the previous execution of the command will be reexamined. Note that negative numbers should be preceded by a `--' argument to avoid confusing them with options.
If two arguments are given, the second specifies the word on the command line in normal array index notation (as a more natural alternative to the numeric argument). Hence 1 is the first word, and -1 (the default) is the last word.
If a third argument is given, its value is ignored, but it is used to signify that the history offset is relative to the current history line, rather than the one remembered after the previous invocations of insert-last-word.
For example, the default behaviour of the command corresponds to
zle insert-last-word -- -1 -1
while the command
zle insert-last-word -- -1 1 -
always copies the first word of the line in the history immediately before the line being edited. This has the side effect that later invocations of the widget will be relative to that line.
If called from a function by the zle command with arguments, the first argument is taken as the string for which to search, rather than the first word in the buffer.
For compatibility with vi, if the command is vi-forward-word or vi-forward-blank-word, the whitespace after the word is not included. If you prefer the more consistent behaviour with the whitespace included use the following key binding:
bindkey -a -s cw dwi
If called from a ZLE widget function in the form `zle copy-region-as-kill string' then string will be taken as the text to copy to the kill buffer. The cursor, the mark and the text on the command line are not used in this case.
With a positive numeric argument N, the word around the cursor, or following it if the cursor is between words, is transposed with the preceding N words. The cursor is put at the end of the resulting group of words.
With a negative numeric argument -N, the effect is the same as using a positive argument N except that the original cursor position is retained, regardless of how the words are rearranged.
Inside a widget function, a call to this function treats the last key of the key sequence which called the widget as the digit.
Inside a widget function, if passed an argument, i.e. `zle universal-argument num', the numeric argument will be set to num; this is equivalent to `NUMERIC=num'.
The function can be used with a command argument inside a user-defined widget. The following code sets the base to 16 and lets the user input a hexadecimal argument until a key out of the digit range is typed:
zle argument-base 16 zle universal-argument
This widget is intended to be called from user-defined widgets to enforce a desired suffix-removal behavior.
This widget is intended to be called from user-defined widgets to enforce a desired suffix-preservation behavior.
When invoked interactively, the pasted text is inserted to the buffer and placed in the cutbuffer. If a numeric argument is given, shell quoting will be applied to the pasted text before it is inserted.
When a named buffer is specified with vi-set-buffer ("x), the pasted text is stored in that named buffer but not inserted.
When called from a widget function as `bracketed-paste name`, the pasted text is assigned to the variable name and no other processing is done.
See also the zle_bracketed_paste parameter.
A restricted set of editing functions is available in the mini-buffer. Keys are looked up in the special command keymap, and if not found there in the main keymap. An interrupt signal, as defined by the stty setting, will abort the function. Note that the following always perform the same task within the executed-named-cmd environment and cannot be replaced by user defined widgets, nor can the set of functions be extended. The allowed functions are: backward-delete-char, vi-backward-delete-char, clear-screen, redisplay, quoted-insert, vi-quoted-insert, backward-kill-word, vi-backward-kill-word, kill-whole-line, vi-kill-line, backward-kill-line, list-choices, delete-char-or-list, complete-word, accept-line, expand-or-complete and expand-or-complete-prefix.
kill-region kills the last word, and vi-cmd-mode is treated the same as accept-line. The space and tab characters, if not bound to one of these functions, will complete the name and then list the possibilities if the AUTO_LIST option is set. Any other character that is not bound to self-insert or self-insert-unmeta will beep and be ignored. The bindings of the current insert mode will be used.
Currently this command may not be redefined or called by name.
Like execute-named-cmd, this command may not be redefined, but it may be called by name.
The following widget, caps-lock, serves as an example.
self-insert-ucase() {
LBUFFER+=${(U)KEYS[-1]}
}
integer stat
zle -N self-insert self-insert-ucase
zle -A caps-lock save-caps-lock
zle -A accept-line caps-lock
zle recursive-edit
stat=$?
zle -A .self-insert self-insert
zle -A save-caps-lock caps-lock
zle -D save-caps-lock
(( stat )) && zle send-break
return $stat
This causes typed letters to be inserted capitalised until either accept-line (i.e. typically the return key) is typed or the caps-lock widget is invoked again; the later is handled by saving the old definition of caps-lock as save-caps-lock and then rebinding it to invoke accept-line. Note that an error from the recursive edit is detected as a non-zero return status and propagated by using the send-break widget.
Otherwise, the prompt is only expanded each time zle starts, and when the display has been interrupted by output from another part of the shell (such as a job notification) which causes the command line to be reprinted.
reset-prompt doesn't alter the special parameter LASTWIDGET.
When a buffer is specified for a cut, change or yank command, the text concerned replaces the previous contents of the specified buffer. If a named buffer is specified using a capital, the newly cut text is appended to the buffer instead of overwriting it. When using the "_ buffer, nothing happens. This can be useful for deleting text without affecting any buffers.
If no buffer is specified for a cut or change command, "1 is used, and the contents of "1 to "8 are each shifted along one buffer; the contents of "9 is lost. If no buffer is specified for a yank command, "0 is used. Finally, a paste command without a specified buffer will paste the text from the most recent command regardless of any buffer that might have been used with that command.
When called from a widget function by the zle command, the buffer can optionally be specified with an argument. For example,
zle vi-set-buffer A
Note that when invoked from vi command mode, the full prior change made in insert mode is reverted, the changes having been merged when command mode was selected.
Text objects are commands that can be used to select a block of text according to some criteria. They are a feature of the vim text editor and so are primarily intended for use with vi operators or from visual selection mode. However, they can also be used from vi-insert or emacs mode. Key bindings listed below apply to the viopp and visual keymaps.
The line editor has the ability to highlight characters or regions of the line that have a particular significance. This is controlled by the array parameter zle_highlight, if it has been set by the user.
If the parameter contains the single entry none all highlighting is turned off. Note the parameter is still expected to be an array.
Otherwise each entry of the array should consist of a word indicating a context for highlighting, then a colon, then a comma-separated list of the types of highlighting to apply in that context.
The contexts available for highlighting are the following:
When region_highlight is set, the contexts that describe a region -- isearch, region, suffix, and paste -- are applied first, then region_highlight is applied, then the remaining zle_highlight contexts are applied. If a particular character is affected by multiple specifications, the last specification wins.
zle_highlight may contain additional fields for controlling how terminal sequences to change colours are output. Each of the following is followed by a colon and a string in the same form as for key bindings. This will not be necessary for the vast majority of terminals as the defaults shown in parentheses are widely used.
The available types of highlighting are the following. Note that not all types of highlighting are available on all terminals:
Not all terminals support this and, of those that do, not all provide facilities to test the support, hence the user should decide based on the terminal type. Most terminals support the colours black, red, green, yellow, blue, magenta, cyan and white, which can be set by name. In addition. default may be used to set the terminal's default foreground colour. Abbreviations are allowed; b or bl selects black. Some terminals may generate additional colours if the bold attribute is also present.
On recent terminals and on systems with an up-to-date terminal database the number of colours supported may be tested by the command `echotc Co'; if this succeeds, it indicates a limit on the number of colours which will be enforced by the line editor. The number of colours is in any case limited to 256 (i.e. the range 0 to 255).
Some modern terminal emulators have support for 24-bit true colour (16 million colours). In this case, the hex triplet format can be used. This consists of a `#' followed by either a three or six digit hexadecimal number describing the red, green and blue components of the colour. Hex triplets can also be used with 88 and 256 colour terminals via the zsh/nearcolor module (see zshmodules(1)).
Colour is also known as color.
The characters described above as `special' are as follows. The formatting described here is used irrespective of whether the characters are highlighted:
Unprintable multibyte characters are shown as a hexadecimal number between angle brackets. The number is the code point of the character in the wide character set; this may or may not be Unicode, depending on the operating system.
Not all systems support this: for it to work, the system's representation of wide characters must be code values from the Universal Character Set, as defined by IS0 10646 (also known as Unicode).
If zle_highlight is not set or no value applies to a particular context, the defaults applied are equivalent to
zle_highlight=(region:standout special:standout suffix:bold isearch:underline paste:standout)
i.e. both the region and special characters are shown in standout mode.
Within widgets, arbitrary regions may be highlighted by setting the special array parameter region_highlight; see above.
| February 14, 2020 | zsh 5.8 |