mirror of
git://git.code.sf.net/p/zsh/code
synced 2025-01-01 05:16:05 +01:00
spelling corrections (13610)
This commit is contained in:
Oliver Kiddle
parent
ffe07b3829
commit
f18221fbb0
13 changed files with 62 additions and 51 deletions
11
ChangeLog
11
ChangeLog
|
|
@ -1,3 +1,14 @@
|
|||
2001-03-12 Oliver Kiddle <opk@zsh.org>
|
||||
|
||||
* 13610: INSTALL, README, Completion/Core/compinit,
|
||||
Completion/Core/compinstall, Doc/Zsh/builtins.yo, Doc/Zsh/compsys.yo
|
||||
Doc/Zsh/compwid.yo, Doc/Zsh/contrib.yo, Doc/Zsh/expn.yo,
|
||||
Doc/Zsh/options.yo, Doc/Zsh/zftpsys.yo, Etc/CONTRIBUTORS: spelling
|
||||
corrections and improve to wording
|
||||
|
||||
* unposted: Completion/Commands/_complete_help: fix to declare tmp
|
||||
as a local variable
|
||||
|
||||
2001-03-12 Chmouel Boudjnah <chmouel@mandrakesoft.com>
|
||||
|
||||
* 13605: Completion/User/_tar, Completion/User/_tar_archive: New tar
|
||||
|
|
|
|||
|
|
@ -109,7 +109,7 @@ done
|
|||
typeset -gA _comps _services _patcomps _postpatcomps _compautos
|
||||
|
||||
# The associative array use to report information about the last
|
||||
# cmpletion to the outside.
|
||||
# completion to the outside.
|
||||
|
||||
typeset -gA _lastcomp
|
||||
|
||||
|
|
@ -165,7 +165,7 @@ comppostfuncs=()
|
|||
# trying to find a function defined for the command on the line if no
|
||||
# such function could be found.
|
||||
# With the `-k' option a function for a special completion keys is
|
||||
# defined and immediatly bound to those keys. Here, the extra arguments
|
||||
# defined and immediately bound to those keys. Here, the extra arguments
|
||||
# are the name of one of the builtin completion widgets and any number
|
||||
# of key specifications as accepted by the `bindkey' builtin.
|
||||
# In any case the `-a' option may be given which makes the function
|
||||
|
|
|
|||
|
|
@ -717,7 +717,7 @@ c. Set condition to perform completion: ${compl:-unset}
|
|||
case $key in
|
||||
g) vared -eh -c -p 'globbing condition> ' glob
|
||||
;;
|
||||
s) vared -eh -c -p 'substituion condition> ' subst
|
||||
s) vared -eh -c -p 'substitution condition> ' subst
|
||||
;;
|
||||
c) vared -eh -c -p 'completion condition> ' compl
|
||||
;;
|
||||
|
|
@ -768,7 +768,7 @@ __ci_do_completers() {
|
|||
_correct
|
||||
'Correction: correct existing word, no completion.'
|
||||
_expand
|
||||
'Expansion: use globbing and parameter substituion, if possible.'
|
||||
'Expansion: use globbing and parameter substitution, if possible.'
|
||||
|
||||
_ignored
|
||||
'Use patterns that were previously ignored if no matches so far.'
|
||||
|
|
@ -923,7 +923,7 @@ __ci_do_matchers() {
|
|||
special way. Numbers in parentheses show matchers to be tried and the order.
|
||||
The same number can be assigned to different matchers, meaning apply at the
|
||||
same time. Omit a sequence number to try normal matching at that point.
|
||||
A \`+' in the first line indicates the element is added to preceeding matchers
|
||||
A \`+' in the first line indicates the element is added to preceding matchers
|
||||
instead of replacing them; toggle this with \`t'. You don't need to set
|
||||
all four, or indeed any matchers --- then the style will not be set.
|
||||
|
||||
|
|
@ -1702,7 +1702,7 @@ while true; do
|
|||
print "\
|
||||
*** compinstall: main menu ***
|
||||
Note that hitting \`q' in menus does not abort the set of changes from
|
||||
lower level menus. However, qutting at top level will ensure that nothing
|
||||
lower level menus. However, quitting at top level will ensure that nothing
|
||||
at all is actually written out.
|
||||
|
||||
1. Completers: choose completion behaviour for tasks such as
|
||||
|
|
|
|||
|
|
@ -834,7 +834,7 @@ Note that read does not attempt to alter the input processing mode. The
|
|||
default mode is canonical input, in which an entire line is read at a time,
|
||||
so usually `tt(read -t)' will not read anything until an entire line has
|
||||
been typed. However, when reading from the terminal with tt(-k)
|
||||
this is automatically handled; note that only availablity of the first
|
||||
this is automatically handled; note that only availability of the first
|
||||
character is tested, so that e.g. `tt(read -t -k 2)' can still block on the
|
||||
second character.
|
||||
)
|
||||
|
|
@ -1610,7 +1610,7 @@ of things implemented by modules. In this case, any aliases are
|
|||
automatically resolved and the tt(-A) flag is not used.
|
||||
)
|
||||
item(tt(zmodload) tt(-A) [ tt(-L) ] [ var(modalias)[tt(=)var(module)] ... ])(
|
||||
For each argument, if both var(modlias) and var(module) are given,
|
||||
For each argument, if both var(modalias) and var(module) are given,
|
||||
define var(modalias) to be an alias for the module var(module).
|
||||
If the module var(modalias) is ever subsequently requested, either via a
|
||||
call to tt(zmodload) or implicitly, the shell will attempt to load
|
||||
|
|
|
|||
|
|
@ -204,7 +204,7 @@ can be bound to any other keys using tt(bindkey) as usual.
|
|||
)
|
||||
item(tt(#compdef -K) var(widget-name) var(style) var(key-sequences) ...)(
|
||||
This is similar to tt(-k), with the same var(style) and var(key-sequences)
|
||||
arguments, preceeded by a string giving the name of a widget.
|
||||
arguments, preceded by a string giving the name of a widget.
|
||||
In this case only one var(key-sequences) argument may be given, but the
|
||||
entire set of three arguments may be repeated with a different set of
|
||||
arguments. In particular, the var(widget-name) must be distinct in each
|
||||
|
|
@ -334,7 +334,7 @@ subsect(Overview)
|
|||
When completion is attempted somewhere on a command line the
|
||||
completion system first tries to find out the context where completion
|
||||
was tried. The context depends on such things as the name of the
|
||||
command when completing an argument, and possibily also
|
||||
command when completing an argument, and possibly also
|
||||
the name of an option when completing an argument to that option.
|
||||
|
||||
The `context' of a completion is a string consisting of multiple fields. This
|
||||
|
|
@ -1601,7 +1601,7 @@ item(tt(max-errors))(
|
|||
This is used by the tt(_approximate) and tt(_correct) completer functions
|
||||
to determine the maximum number of errors to allow. The completer will try
|
||||
to generate completions by first allowing one error, then two errors, and
|
||||
so on, until either a match or matches wer found or the maximum number of
|
||||
so on, until either a match or matches were found or the maximum number of
|
||||
errors given by this style has been reached.
|
||||
|
||||
If the value for this style contains the string `tt(numeric)', the
|
||||
|
|
@ -1748,8 +1748,8 @@ the number of errors that were accepted.
|
|||
kindex(regular, completion style)
|
||||
item(tt(regular))(
|
||||
This style is used by the tt(_expand_alias) completer and bindable
|
||||
command. If is set to `true' (the default) regular alias will be
|
||||
expanded only in command position. If it is set to `false', regular
|
||||
command. If set to `true' (the default), regular aliases will be
|
||||
expanded but only in command position. If it is set to `false', regular
|
||||
aliases will never be expanded and if it is set to the string
|
||||
`tt(always)', regular aliases will be expanded even if not in command
|
||||
position.
|
||||
|
|
@ -2426,7 +2426,7 @@ tt(glob) and tt(-o) to tt(subst-globs-only).
|
|||
findex(_expand_alias)
|
||||
item(tt(_expand_alias))(
|
||||
If the word the cursor is on is an alias, it is expanded and no other
|
||||
completers are called. Which types of aliases are to be expanded can
|
||||
completers are called. The types of aliases which are to be expanded can
|
||||
be controlled with the tt(regular), tt(global) and tt(disabled)
|
||||
styles.
|
||||
|
||||
|
|
@ -2578,7 +2578,7 @@ tt(_bash_list-choices). It exists to provide compatibility with
|
|||
completion bindings in bash. The last character of the binding determines
|
||||
what is completed: `tt(!)', command names; `tt($)', environment variables;
|
||||
`tt(@)', host names; `tt(/)', file names; `tt(~)' user names. In bash, the
|
||||
binding preceeded by `tt(\e)' gives completion, and preceeded by `tt(^X)'
|
||||
binding preceded by `tt(\e)' gives completion, and preceded by `tt(^X)'
|
||||
lists options. As some of these bindings clash with standard zsh
|
||||
bindings, only `tt(\e~)' and `tt(^X~)' are bound by default. To add the
|
||||
rest, the following should be added to tt(.zshrc) after tt(compinit) has
|
||||
|
|
@ -2609,14 +2609,14 @@ then calls the tt(_correct) completer.
|
|||
findex(_expand_alias (^Xa))
|
||||
item(tt(_expand_alias (^Xa)))(
|
||||
This function can be used as a completer and as a bindable command.
|
||||
It expands the word the cursor on if it is an alias. The types of
|
||||
aliases used can be controlled with the tt(regular), tt(global) and
|
||||
It expands the word the cursor is on if it is an alias. The types of
|
||||
aliases expanded can be controlled with the tt(regular), tt(global) and
|
||||
tt(disabled) styles.
|
||||
|
||||
When used as a bindable command there is one additional feature that
|
||||
can be selected by setting the tt(complete) style to `true'. In this
|
||||
case, if the word isn't the name of an alias, tt(_expand_alias) tries
|
||||
to complete the word to an full alias name without expanding it (but
|
||||
to complete the word to a full alias name without expanding it (but
|
||||
leaving the cursor directly after the completed word so that invoking
|
||||
tt(_expand_alias) once more will expand the now-complete alias name).
|
||||
)
|
||||
|
|
@ -2631,8 +2631,8 @@ item(tt(_generic))(
|
|||
This function is not defined as a widget and not bound by
|
||||
default. However, it can be used to define a widget and will then
|
||||
store the name of the widget in the var(function) field of the context
|
||||
and call the completion system. This allows to easily define custom
|
||||
completion widgets with their own sets of style settings. For example,
|
||||
and call the completion system. This allows custom completion widgets
|
||||
with their own set of style settings to be easily defined. For example,
|
||||
to define a widget that does normal completion and starts
|
||||
menu selection, one could do:
|
||||
|
||||
|
|
@ -2748,7 +2748,7 @@ into the var(args) given to the var(command). Normally, they are put
|
|||
directly after the var(command), but if one of the var(args) is a single
|
||||
hyphen, they are inserted directly before that. If the hyphen is the last
|
||||
argument, that will be removed from the argument list before the
|
||||
var(command) is called. This allows to use tt(_all_labels) in almost all
|
||||
var(command) is called. This allows tt(_all_labels) to be used in almost all
|
||||
cases where the matches can be generated by a single call to the
|
||||
tt(compadd) builtin command or by a call to one of the utility functions.
|
||||
|
||||
|
|
@ -3125,7 +3125,7 @@ option will be completed after a `tt(-)tt(-)' on the line and this
|
|||
argument will otherwise be ignored. With tt(-A), no options will be
|
||||
completed after the first non-option argument on the line. The tt(-A)
|
||||
has to be followed by a pattern matching all strings which are not to
|
||||
be taken as arguemnts. For example, to make tt(_arguments) stop
|
||||
be taken as arguments. For example, to make tt(_arguments) stop
|
||||
completing options after the first normal argument, but ignoring all
|
||||
strings starting with a hyphen even if they are not described by one
|
||||
of the var(optspec)s, one would use: `tt(-A "-*")'.
|
||||
|
|
@ -3134,8 +3134,8 @@ Note that using multiple sets will be slower than using only one set
|
|||
because the completion code has to parse the command line once for
|
||||
every set. So more than one set should only be used if the command
|
||||
syntax is too complicated. Note also that an option specification with
|
||||
rest-arguments (as in `tt(-foo:*:...)') often allows to avoid the use
|
||||
of multiple sets.
|
||||
rest-arguments (as in `tt(-foo:*:...)') often allows the use of
|
||||
multiple sets to be avoided.
|
||||
|
||||
Another option supported is `tt(-O) var(name)'. The var(name) will be
|
||||
taken as the name of an array and its elements will be given to
|
||||
|
|
@ -3202,7 +3202,7 @@ it about this as described for the normal option descriptions above.
|
|||
If the var(pattern) ends in `tt((-))', this will removed from the
|
||||
pattern and the var(action) will be used only directly after the
|
||||
`tt(=)', not in the next word. I.e., this is like a normal
|
||||
specification as descrobed above using `tt(=-)'.
|
||||
specification as described above using `tt(=-)'.
|
||||
|
||||
The option `tt(-i) var(patterns)' (which must be given after the
|
||||
`tt(-)tt(-)') can be used to give patterns for options which should not be
|
||||
|
|
@ -3573,10 +3573,10 @@ This function is a compiler to generate a completion function. The
|
|||
first argument specifies the name of the generated function while the
|
||||
remaining arguments specify a completion as a set of regular
|
||||
expressions with actions. The generated function has the structure of a
|
||||
finite-state machine whose states corresponds to the state (i.e. the
|
||||
finite-state machine whose states correspond to the state (i.e. the
|
||||
context) of the completion. This state machine uses a command line,
|
||||
which comes from concatenating the tt(words) array up to the current
|
||||
cursor position using null characters as separators with no extra
|
||||
which comes from the concatenation of the tt(words) array up to the
|
||||
current cursor position using null characters as separators with no extra
|
||||
quotation. This is analysed and at the end the appropriate action is
|
||||
executed.
|
||||
|
||||
|
|
@ -3589,9 +3589,9 @@ item(tt(/)var(pattern)tt(/) [tt(%)var(lookahead)tt(%)] [tt(-)var(guard)] [tt(:)v
|
|||
This is a primitive element, corresponding to one
|
||||
state of the compiled state machine. The state is entered if
|
||||
`tt((#b)LPAR()(#B))var(pattern)tt(RPAR()(#B))var(lookahead)tt(*)' matches
|
||||
the command line string. If it is matched, `var(guard)' is evaluated and
|
||||
the command line string. If it matches, `var(guard)' is evaluated and
|
||||
its return status is examined; if this is successful, the state is entered,
|
||||
else the test fails and other candidates are tried. The var(pattern)
|
||||
otherwise the test fails and other candidates are tried. The var(pattern)
|
||||
string `tt([])' is guaranteed never to match.
|
||||
|
||||
If the test succeeds and the state is entered, the left part of the
|
||||
|
|
@ -3605,12 +3605,12 @@ command line string and var(action)s for the target are executed.
|
|||
In this case, nothing is actually removed from the command line string
|
||||
so that any previous or neighbouring state may also have var(actions)s.
|
||||
var(actions)s evaluation are ordered by the tt(tag-order) style and specified
|
||||
var(tag) by tt(_alternative). So, various format supported by tt(_alternative)
|
||||
can be used in var(action). var(descr) is used for set up the array parameter
|
||||
tt(expl).
|
||||
var(tag) by tt(_alternative). So, the various formats supported by
|
||||
tt(_alternative) can be used in var(action). var(descr) is used for
|
||||
setting up the array parameter tt(expl).
|
||||
)
|
||||
item(tt(/)var(pattern)tt(/+) [tt(%)var(lookahead)tt(%)] [tt(-)var(guard)] [tt(:)var(tag)tt(:)var(descr)tt(:)var(action)])(
|
||||
This is similar to `tt(/)var(pattern)tt(/) ...' but the left part of
|
||||
This is similar to `tt(/)var(pattern)tt(/) ...' but the left part of the
|
||||
command line string is also considered as part of the completion target.
|
||||
)
|
||||
item(tt(/)var(pattern)tt(/-) [tt(%)var(lookahead)tt(%)] [tt(-)var(guard)] [tt(:)var(tag)tt(:)var(descr)tt(:)var(action)])(
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ 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(zshcompctly))\
|
||||
ifzman(zmanref(zshcompctl))\
|
||||
ifnzman(the chapter noderef(Completion Using compctl)).
|
||||
|
||||
Completion widgets are defined by the tt(-C) option to the tt(zle)
|
||||
|
|
@ -410,7 +410,7 @@ 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(uanmbiguous) key.
|
||||
given by the value of the tt(unambiguous) key.
|
||||
)
|
||||
vindex(vared, compstate)
|
||||
item(tt(vared))(
|
||||
|
|
@ -656,7 +656,7 @@ 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 metches
|
||||
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
|
||||
|
|
@ -851,7 +851,7 @@ 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
|
||||
preceeded by the pattern var(lanchor). The var(lanchor) can be blank to
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -111,7 +111,7 @@ Without the tt(-t) option, the return status is zero if all files that
|
|||
needed re-compilation could be compiled and non-zero if compilation for at
|
||||
least one of the files failed.
|
||||
|
||||
If the tt(-p) option is given, the var(args) are interepted as one
|
||||
If the tt(-p) option is given, the var(args) are interpreted as one
|
||||
or more sets of arguments for tt(zcompile), separated by `tt(-)tt(-)'.
|
||||
For example:
|
||||
|
||||
|
|
@ -326,7 +326,7 @@ position it considers to be the most interesting one, i.e. the one
|
|||
where one can disambiguate between as many matches as possible with as
|
||||
little typing as possible.
|
||||
|
||||
This widget allows to easily move the cursor to the other interesting
|
||||
This widget allows the cursor to be easily moved to the other interesting
|
||||
spots. It can be invoked repeatedly to cycle between all positions
|
||||
reported by the completion system.
|
||||
)
|
||||
|
|
@ -367,7 +367,7 @@ Typing the keystrokes for this widget with the cursor placed on or to the
|
|||
left of an integer causes that integer to be incremented by one. With a
|
||||
numeric prefix argument, the number is incremented by the amount of the
|
||||
argument (decremented if the prefix argument is negative). The shell
|
||||
paramter tt(incarg) may be set to change the default increment something
|
||||
parameter tt(incarg) may be set to change the default increment something
|
||||
other than one.
|
||||
|
||||
example(bindkey '^X+' incarg)
|
||||
|
|
|
|||
|
|
@ -1248,7 +1248,7 @@ The precedence of the operators given above is (highest) `tt(^)', `tt(/)',
|
|||
`tt(~)', `tt(|)' (lowest); the
|
||||
remaining operators are simply treated from left to right as part of a
|
||||
string, with `tt(#)' and `tt(##)' applying to the shortest possible
|
||||
preceeding unit (i.e. a character, `tt(?)', `tt([)...tt(])',
|
||||
preceding unit (i.e. a character, `tt(?)', `tt([)...tt(])',
|
||||
`tt(<)...tt(>)', or a parenthesised expression). As mentioned
|
||||
above, a `tt(/)' used as a directory separator may not appear inside
|
||||
parentheses, while a `tt(|)' must do so; in patterns used in other contexts
|
||||
|
|
|
|||
|
|
@ -254,7 +254,7 @@ cindex(symbolic links)
|
|||
item(tt(CHASE_LINKS) (tt(-w)))(
|
||||
Resolve symbolic links to their true values when changing directory.
|
||||
This also has the effect of tt(CHASE_DOTS), i.e. a `tt(..)' path segment
|
||||
will be treated as referring to the physical parent, even if the preceeding
|
||||
will be treated as referring to the physical parent, even if the preceding
|
||||
path segment is a symbolic link.
|
||||
)
|
||||
pindex(CHECK_JOBS)
|
||||
|
|
|
|||
|
|
@ -493,7 +493,7 @@ unless the output is going to a terminal; however, if you transfer files in
|
|||
the background, you should turn off progress reports by hand using
|
||||
`tt(zstyle ':zftp:*' progress none)'. Note also that if you alter it, any
|
||||
output em(must) be to standard error, as standard output may be a file
|
||||
being received. The form of the progess meter, or whether it is used at
|
||||
being received. The form of the progress meter, or whether it is used at
|
||||
all, can be configured without altering the function, as described in the
|
||||
next section.
|
||||
)
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ configuration, completion functions.
|
|||
|
||||
Chmouel Boudjnah <chmouel@mandrakesoft.com>: configuration support.
|
||||
|
||||
Wayne Davison <wayned@users.sourceforege.net>: History code.
|
||||
Wayne Davison <wayned@users.sourceforge.net>: History code.
|
||||
|
||||
Alexandre Duret-Lutz: completion functions and substitution code.
|
||||
|
||||
|
|
@ -50,11 +50,11 @@ Tanaka Akira <akr@zsh.org>: Completion and test functions.
|
|||
Geoff Wing <gcw@zsh.org>: FTP and mailing list archive
|
||||
|
||||
Sven Wischnowsky <wischnow@zsh.org>: Most of the completion code, zpty,
|
||||
signal queuing, parameters, builtins, builtouts, built-here-and-theres;
|
||||
signal queueing, parameters, builtins, builtouts, built-here-and-theres;
|
||||
mend garden shed, rewire electricity, reinstall shutters, fix TV aerial in
|
||||
howling gale...
|
||||
|
||||
Other patches from E. Jay Birkenbilt,, Jan Fedak, Ulrik Haugen, Paul
|
||||
Other patches from E. Jay Birkenbilt, Jan Fedak, Ulrik Haugen, Paul
|
||||
Johnson, Fr. Br. George (George V Kouryachy).
|
||||
|
||||
Versions 3.1.7 to 3.1.9
|
||||
|
|
@ -84,7 +84,7 @@ Versions 3.1.7 to 3.1.9
|
|||
for completion system, documentation, various other fixes
|
||||
|
||||
* Bart Schaefer <schaefer@zsh.org>: documentation and many other bits,
|
||||
archive maintainance
|
||||
archive maintenance
|
||||
|
||||
* Adam Spiers <adam@spiers.net>: various completion functions, source code
|
||||
archive maintenance, documentation fixes, prompt themes
|
||||
|
|
|
|||
2
INSTALL
2
INSTALL
|
|
@ -261,7 +261,7 @@ can be overriden using one of the options below when invoking "configure".
|
|||
|
||||
Any startup/shutdown script can be disabled by giving the
|
||||
--disable-scriptname option to "configure". The --disable-etcdir option
|
||||
disables all startup/shutdown files which are not explicitely enabled.
|
||||
disables all startup/shutdown files which are not explicitly enabled.
|
||||
|
||||
Shell functions
|
||||
---------------
|
||||
|
|
|
|||
4
README
4
README
|
|
@ -23,7 +23,7 @@ Zsh is a shell with lots of features. For a list of these, see the
|
|||
file Etc/FEATURES, and for the latest changes see Etc/NEWS. For more
|
||||
details, see the documentation.
|
||||
|
||||
Possibile incompatibilities
|
||||
Possible incompatibilities
|
||||
---------------------------
|
||||
|
||||
If you have been using recent versions of zsh 3.1, the following changes in
|
||||
|
|
@ -95,7 +95,7 @@ script about its usage. The files created by this script can be used
|
|||
by example function run-help located in the subdirectory Functions/Misc to
|
||||
show information about zsh builtins and run `man' on external commands.
|
||||
For this the shell variable HELPDIR should point to a directory containing
|
||||
the fileles generated by the helpfiles script. run-help should be
|
||||
the files generated by the helpfiles script. run-help should be
|
||||
unaliased before loading the run-help function. After that this function
|
||||
will be executed by the run-help ZLE function which is by default bound
|
||||
to ESC-h in emacs mode.
|
||||
|
|
|
|||
Loading…
Reference in a new issue