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:
parent
6398d0e2bc
commit
76953c4d3f
5 changed files with 65 additions and 64 deletions
|
|
@ -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 `*'?
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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)).
|
||||
)
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue