1
0
Fork 0
mirror of git://git.code.sf.net/p/zsh/code synced 2025-10-27 04:40:59 +01:00

zsh-workers/9827

This commit is contained in:
Tanaka Akira 2000-02-22 01:43:02 +00:00
parent 6398d0e2bc
commit 76953c4d3f
5 changed files with 65 additions and 64 deletions

View file

@ -19,7 +19,7 @@ local curcontext="${curcontext/:[^:]#:/:match:}"
tmp="${${:-$PREFIX$SUFFIX}#[~=]}"
[[ "$tmp:q" = "$tmp" ]] && return 1
zstyle -s ":completion:${curcontext}:" original orig
zstyle -s ":completion:${curcontext}:" match-original orig
zstyle -b ":completion:${curcontext}:" insert-unambiguous ins
# Try completion without inserting a `*'?

View file

@ -4,10 +4,10 @@
local curcontext="${curcontext/:[^:]#:/:oldlist:}" list
zstyle -s ":completion:${curcontext}:" list list
zstyle -s ":completion:${curcontext}:" old-list list
# If this is a listing widget and there is already an old list,
# and either the style :oldlist:list is `always', or it is not `never'
# and either the style :oldlist:old-list is `always', or it is not `never'
# and the list is not already shown, then use the existing list for listing
# (even if it was generated by another widget).
# Do this also if there is an old list and it was generated by the
@ -30,13 +30,13 @@ if [[ -n $compstate[old_list] && $list != never ]]; then
fi
# If this is a completion widget, and we have a completion inserted already,
# and the style :oldlist:menu is `true', then we cycle through the
# and the style :oldlist:old-menu is `true', then we cycle through the
# existing list (even if it was generated by another widget).
if [[ -z $compstate[old_insert] && -n $compstate[old_list] ]]; then
compstate[old_list]=keep
elif [[ $WIDGET = *complete(|-prefix|-word) ]] &&
zstyle -t ":completion:${curcontext}:" menu; then
zstyle -t ":completion:${curcontext}:" old-menu; then
if [[ -n $compstate[old_insert] ]]; then
compstate[old_list]=keep
if [[ $WIDGET = *reverse* ]]; then

View file

@ -989,38 +989,10 @@ this is independent of the numeric argument -- unlike the
tt(ALWAYS_LAST_PROMPT) option.
)
item(tt(list))(
This is used by the tt(_oldlist) completer (context
`tt(:completion:oldlist)'), the tt(_history_complete_word) bindable command
This is used by the tt(_history_complete_word) bindable command
(context `tt(:completion:history-words)') and by the
tt(incremental-complete-word) widget (context `tt(:completion:incremental)).
For tt(_oldlist), if this is set to tt(always), then standard
widgets which perform listing will retain the current list of matches,
however they were generated. If it is set to tt(never), this will not
be done (the behaviour without the tt(_oldlist) completer). If it is
unset, or any other value, then the existing list of completions will
be displayed if it is not already; otherwise, the standard completion
list will be generated: this is the default behaviour of
tt(_oldlist). However, if there is an old list and this style contains
the name of the completer function that generated the list, then the
old list will be used even if it was generated by a widget which does
not do listing.
For example, suppose you type tt(^Xc) to use the tt(_correct_word)
widget, which generates a list of corrections for the word under the
cursor. Usually, typing tt(^D) would generate a standard list of
completions for the word on the command line, and show that. With
tt(_oldlist), it will instead show the list of corrections already
generated.
As another example consider the tt(_match) completer: with the
tt(insert-unambiguous) style set to `true' it inserts only an
unambiguous prefix string if there is any. But since this may remove
parts of the original pattern, attempting completion again may result
in more matches than on the first attempt. But by using the
tt(_oldlist) completer and setting this style to tt(_match), the list of
matches generated on the first attempt will be used again.
The tt(_history_complete_word) bindable command uses this style to
decide if the available matches should be shown.
@ -1083,6 +1055,14 @@ hostname, the path to the default web pages for the server and the
directory name used by a user placing web pages within their home
area.
)
item(tt(match-original))(
This is used by the tt(_match) completer. If it is set to
tt(only), tt(_match) will try to generate matches without inserting a
`tt(*)' at the cursor position. If set to any other non-empty value,
it will first try to generate matches without inserting the `tt(*)'
and if that yields no matches, it will try again with the `tt(*)'
inserted.
)
item(tt(matcher))(
This style is tested for tags used when generating matches. Its value
is used as an additional match specification to use when adding the
@ -1188,8 +1168,46 @@ it will be started only if at least that many matches are generated
smallest one is taken). Starting menuselection can explicitly be
turned off by defining a value containing the string
tt(no-select).
)
item(tt(numbers))(
This is used with the tt(jobs) tag. If it is `true', the completions
will use the job numbers instead of the shortest unambiguous strings
of the jobs' command lines. If the value is a number, job numbers will
only be used if for at least one of the jobs that many (or more) words
from the command line string have to be used to make the strings
unambiguous. E.g. if it is set to `tt(1)', strings will only be used
if all jobs differ in the first word on their command lines.
)
item(tt(old-list))(
This is used by the tt(_oldlist) completer. If this is set to tt(always),
then standard widgets which perform listing will retain the current list of
matches, however they were generated. If it is set to tt(never), this will
not be done (the behaviour without the tt(_oldlist) completer). If it is
unset, or any other value, then the existing list of completions will
be displayed if it is not already; otherwise, the standard completion
list will be generated: this is the default behaviour of
tt(_oldlist). However, if there is an old list and this style contains
the name of the completer function that generated the list, then the
old list will be used even if it was generated by a widget which does
not do listing.
This is also used by the tt(_oldlist) completer. Here it controls how menu
For example, suppose you type tt(^Xc) to use the tt(_correct_word)
widget, which generates a list of corrections for the word under the
cursor. Usually, typing tt(^D) would generate a standard list of
completions for the word on the command line, and show that. With
tt(_oldlist), it will instead show the list of corrections already
generated.
As another example consider the tt(_match) completer: with the
tt(insert-unambiguous) style set to `true' it inserts only an
unambiguous prefix string if there is any. But since this may remove
parts of the original pattern, attempting completion again may result
in more matches than on the first attempt. But by using the
tt(_oldlist) completer and setting this style to tt(_match), the list of
matches generated on the first attempt will be used again.
)
item(tt(old-menu))(
This is used by the tt(_oldlist) completer. Here it controls how menu
completion behaves when a completion has already been inserted and the
user types a standard completion key type such as tt(TAB). The default
behaviour of tt(_oldlist) is that menu completion always continues
@ -1204,32 +1222,15 @@ tt(TAB) at this point would start trying to complete the line as it now
appears. With tt(_oldlist), it will instead continue to cycle through the
list of completions.
)
item(tt(numbers))(
This is used with the tt(jobs) tag. If it is `true', the completions
will use the job numbers instead of the shortest unambiguous strings
of the jobs' command lines. If the value is a number, job numbers will
only be used if for at least one of the jobs that many (or more) words
from the command line string have to be used to make the strings
unambiguous. E.g. if it is set to `tt(1)', strings will only be used
if all jobs differ in the first word on their command lines.
)
item(tt(original))(
This is used by the tt(_approximate), tt(_correct) and tt(_match)
completers. The first two use it to decide if the original string should
be added as one possible completion. Normally, this is done only if
there are
This is used by the tt(_approximate) and tt(_correct)
completers to decide if the original string should be added as
one possible completion. Normally, this is done only if there are
at least two possible corrections, but if this style is set to `true', it
will always be added. Note that these completers use this style after
setting the completer field in the context name to
tt(correct-)var(num) or tt(approximate-)var(num), where var(num) is
the number of errors that were accepted.
For the tt(_match) completer, if this style is set to
tt(only), it will try to generate matches without inserting a
`tt(*)' at the cursor position. If set to any other non-empty value,
it will first try to generate matches without inserting the `tt(*)'
and if that yields no matches, it will try again with the `tt(*)'
inserted.
)
item(tt(packageset))(
A style containing an override for the default package set
@ -1634,8 +1635,8 @@ 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
tt(original) style has a value of tt(only), no `tt(*)' will be
inserted. If tt(original) has any other non-empty string as its
tt(match-original) style 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.
@ -1693,8 +1694,8 @@ This completer controls how the standard completion widgets behave
when there is an existing list of completions which may have been
generated by a special completion (i.e. a separately-bound completion
command). It should appear in the list of completers before any of
the widgets which generate matches. It uses two styles: tt(list) and
tt(menu), see
the widgets which generate matches. It uses two styles: tt(old-list) and
tt(old-menu), see
ifzman(the section `Completion System Configuration' above)\
ifnzman(noderef(Completion System Configuration)).
)

View file

@ -554,7 +554,7 @@ actual time interval is limited only by tt($ZFTP_TIMEOUT).
As described for tt(progress), tt(zfinit) will force this to default to 1.
)
item(tt(remote_glob))(
item(tt(remote-glob))(
If set to `1', `yes' or `true', filename generation (globbing) is
performed on the remote machine instead of by zsh itself; see below.
)
@ -598,7 +598,7 @@ within the current directory. The list of files in the current directory,
if retrieved, will be cached, so that subsequent globs in the same
directory without an intervening tt(zfcd) are much faster.
If the tt(remote_glob) style (see above) is set, globbing is instead
If the tt(remote-glob) style (see above) is set, globbing is instead
performed on the remote host: the server is asked for a list of matching
files. This is highly dependent on how the server is implemented, though
typically UNIX servers will provide support for basic glob patterns. This

View file

@ -9,7 +9,7 @@
# stick with a single directory. This is the default.
# (2) Use remote globbing, i.e. pass it to ls at the site.
# Faster, but only works with UNIX, and only basic globbing.
# We do this if the remote_glob style (or $zfrglob for
# We do this if the remote-glob style (or $zfrglob for
# backward compatibility) is set.
# There is only one argument, the variable containing the
@ -21,7 +21,7 @@ setopt extendedglob
local pat dir nondir files i zfrglob
zstyle -t "$curcontext" remote_glob && zfrglob=1
zstyle -t "$curcontext" remote-glob && zfrglob=1
eval pat=\$$1