* Completion issues
@ 2000-04-01 20:26 Peter Stephenson
2000-04-02 3:16 ` Bart Schaefer
0 siblings, 1 reply; 8+ messages in thread
From: Peter Stephenson @ 2000-04-01 20:26 UTC (permalink / raw)
To: Zsh hackers list
Thanks to some notes from Sven, I was able to update chapter six of the
user guide, during which these matters arose. When I understand them, I'll
upload the new version. If that passes muster, I'll transfer it to the
main zsh web site. I know Sven has actually asked about some of these,
including the first one.
First, I hate the new behaviour of _complete_help. I use it to find out
what context I'm in. Unfortunately I don't get to see that, because a huge
list of style has scrolled by. This is useful information, but should be
decanted to another function --- perhaps _complete_long_help, with the
default binding ^X^H (? ^H has other uses, so maybe there's something
better). I don't think a style to turn off styles in ^Xh is good enough,
there's too much mucking around, and you may want the style information
anyway. A workable alternative is that a numeric argument activates the
style list --- this feature could be configurable by a style.
Second, if I understood correctly, the default behaviour for completion is
to ignore ignored completions completely. Thus the behaviour of $fignore
has changed. If this is right, _ignored should definitely be added to the
default completers. Certainly people may prefer it without, but it should
be up to them to change the old behaviour.
Next, I'm in a mess with the tag label stuff. First of all,
I tried this:
zstyle ':completion:*:*:-command-:*' tag-order \
'functions:-non-comp:non-completion\ functions *' functions
zstyle ':completion:*:functions-non-comp' ignored-patterns '_*'
pretty much what's in the manual, except with a name. Now listing
completions for zfl gives me
Completing non-completion functions
zfls
Completing shell function
zfls
Completing alias
zfls
Forget the last one; arguably you should only get the alias in this case,
since that's what will actually run, but I can see that's a
sophistication. It's a bit annoying that I get the same function, for the
same tag, both with filtering and without. With a long list it's going to
be worse. Have I missed something?
Also, if I remember right the tag label stuff was partly inspired by the
example in the guide about ignoring functions matching `_*'. That can
still be done using _ignored; Sven's sent me how to do that for the guide.
It can also be done by:
zstyle ':completion:*' tag-order functions:-non-comp
zstyle ':completion:*:functions-non-comp' ignored-patterns '_*'
(for some reason didn't seem to work before, but does now, so I presume I
fouled up). The only problem there is I don't really want to upset the
global tag-order for what is really a local problem for one tag. So I
replaced the first line with:
zstyle ':completion:*:functions' tag-order functions:-non-comp
This doesn't work, and I can understand why it wouldn't --- looking up a
tag using a tag is distinctly odd. But the manual implies this works with
options:
zstyle ':completion:*:options' tag-order 'options:-long:long options
options:-short:short options
options:-single-letter:single letter options'
(formatted here with a ghastly offset of some thirty characters but I
suppose that's my problem). As a subsidiary question, what happened to the
backslashes the manual claims are needed for the spaces in the names? More
importantly, what the heck's going on? Apparently looking up the tag
`options' will, after all, force a re-lookup with options split into three.
As far as I can see, this example is the only thing in the manual which
tells you one way or the other whether you can explicitly split up tags
into sub-tags like this. I'm now distinctly confused. Explanation?
I came across the same problem when trying to explain _next_label using the
code in _mh. Looking at the code, which is this:
if _wanted sequences; then
while _next_label sequences expl sequence; do
compadd "$expl[@]" $(mark $foldnam 2>/dev/null |
awk -F: '{ print $1 }') &&
ret=0
compadd "$expl[@]" reply next cur prev first last all unseen && ret=0
_files "$expl[@]" -W folddir -g '<->' && ret=0
(( ret )) || return 0
done
I would expect the following to work:
zstyle ':completion:*:sequences' tag-order sequences:-name sequences:-num
zstlye ':completion:*:sequences-name' ignored-patterns '<->'
zstyle ':completion:*:sequences-num' ignored-patterns '^<->'
prefering named sequences to messages which are just numbers. But it
doesn't. I noted that despite being inside the _wanted, _files is used
instead of _path_files, so I thought maybe it was using the files tag, but
assuming a split into `sequences' and `files' doesn't seem to work either.
What's the right way of doing this?
By the way, the example given in the manual of ignored-patterns and tag
labels,
zstyle ':completion:*:*:-command-:*' tag-order 'functions:-non-comp'
zstyle ':completion:*:functions-non-comp' ignored-patterns '_*'
(= in command position, prefer the `functions' tag but use it with the name
functions-non-comp; anywhere you see that tag, exclude patterns matching
`_*) isn't particularly good, since the issue only really arises in command
position after you've typed a character, hence you really need
correction/approximation to test this, and it's hard to think of an
example. I've borrowed this from the manual until I or someone else can
think of another clean, simple example.
Another thing: I couldn't get matcher-list to work for a labelled
completer, e.g. _complete:-extended. When I switched to matcher instead,
it worked fine. This fit my preconception, when I eventually decided what
that would have been, because I though matcher-list was decided once right
at the start. However, the manual explicitly says that you can use
matcher-list with labelled completers.
Tail-ender: this is a real bug:
% zsh -f
% autoload -U compinit; compinit -D
% zstyle ':completion:*' completer _expand _complete
% zstyle ':<TAB>
^this gets replaced by an character from the upper end of
ISO-8859-1 which I didn't particularly want to see.
The style subst-globs-only is several times referred to without the
plural, which is particularly annoying in _zstyle, but also occurs in the
doc. (No patch, since it's almost half past midnight and I like to eat
this evening.)
This is probably known, but _next_tags doesn't work well with menu
completion. Ideally, it should probably remove the current choice if the
last command was a menu completion and replace it with the first choice
from the list generated with the next tag. Also, the message at the top
doesn't change; you still see `Completing TeX or LaTeX file' if you cycle
through to completing directories. Maybe this is a feature.
--
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@CambridgeSiliconRadio.com
Web: http://www.pwstephenson.fsnet.co.uk
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Completion issues
2000-04-01 20:26 Completion issues Peter Stephenson
@ 2000-04-02 3:16 ` Bart Schaefer
0 siblings, 0 replies; 8+ messages in thread
From: Bart Schaefer @ 2000-04-02 3:16 UTC (permalink / raw)
To: Peter Stephenson, Zsh hackers list
On Apr 1, 9:26pm, Peter Stephenson wrote:
} Subject: Completion issues
}
} First, I hate the new behaviour of _complete_help. I use it to find out
} what context I'm in. Unfortunately I don't get to see that, because a huge
} list of style has scrolled by.
I won't say I *hate* the new behavior, but I was certainly alarmed by the
amount of style output that was generated even for something like "ls" or
"echo" that doesn't have any special handling. "cvs <^Xh>" is horrifying.
That list-colors, list-packed, list-rows-first, last-prompt, accept-exact,
and menu appear no less than 8 times each seems a tad excessive.
} I don't think a style to turn off styles in ^Xh is good enough,
} there's too much mucking around, and you may want the style information
} anyway. A workable alternative is that a numeric argument activates the
} style list --- this feature could be configurable by a style.
I like the numeric-argument idea. If we wanted to get really fancy, a
number from 1-4 could denote increasingly verbose output, so that using
universal-argument would produce the full-blown listing.
I'm not convinced we'd need a style to make that configurable, though.
It's pretty straightforward to create a zle widget that sets NUMERIC and
then calls another widget.
} Second, if I understood correctly, the default behaviour for completion is
} to ignore ignored completions completely. Thus the behaviour of $fignore
} has changed.
Unless I'm getting the wrong version of a function, it appears that this
is special-cased by _path_files so that $fignore has not changed -- but
if you use the ignored-patterns style instead, then ignored completions
really are ignored, and you need to add the _ignored completer to get
the old behavior back.
For the rest of the stuff you mentioned, I'm even more lost than you.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Completion issues
@ 2000-04-06 7:31 Sven Wischnowsky
0 siblings, 0 replies; 8+ messages in thread
From: Sven Wischnowsky @ 2000-04-06 7:31 UTC (permalink / raw)
To: zsh-workers
Peter Stephenson wrote:
> > > Another thing: I couldn't get matcher-list to work for a labelled
> > > completer, e.g. _complete:-extended.
>
> This seems to work this time. Don't what I did wrong. So what's the
> difference between matcher and matcher-list now? The latter is looked up
> once for a completer (but again if we have a labelled completer), but the
> latter is looked up every single time we add a match?
Two main differences:
1) matcher is tested for the most specific contexts possible,
including the tags, matcher-list, as you said, only for the
completer
2) matcher-list uses its values on after another (there is a loop),
matcher uses all its values in one go
But, yes, with completer-labelling one could replace matcher-list with
a couple of matcher styles settings. Exactly because of that `couple of'
I kept matcher-list -- it's so much more convenient.
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Completion issues
2000-04-03 15:25 Sven Wischnowsky
@ 2000-04-05 18:30 ` Peter Stephenson
0 siblings, 0 replies; 8+ messages in thread
From: Peter Stephenson @ 2000-04-05 18:30 UTC (permalink / raw)
To: zsh-workers
Sven Wischnowsky wrote:
> Hm. Should we add a tag-labels style again (tested for every tag in
> tag-order, gives labels to use for this tag in its value)? My main
> reason for not liking this that much is the fact that it's in C now --
> I wanted to avoid having style-lookups hidden in some C-function.
As long as it works, which it does now, I'm not worried.
> > I would expect the following to work:
> > zstyle ':completion:*:sequences' tag-order sequences:-name sequences:-num
> > zstlye ':completion:*:sequences-name' ignored-patterns '<->'
> > zstyle ':completion:*:sequences-num' ignored-patterns '^<->'
This now works, too
> > Another thing: I couldn't get matcher-list to work for a labelled
> > completer, e.g. _complete:-extended.
This seems to work this time. Don't what I did wrong. So what's the
difference between matcher and matcher-list now? The latter is looked up
once for a completer (but again if we have a labelled completer), but the
latter is looked up every single time we add a match?
--
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@CambridgeSiliconRadio.com
Web: http://www.pwstephenson.fsnet.co.uk
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Completion issues
@ 2000-04-04 9:49 Sven Wischnowsky
0 siblings, 0 replies; 8+ messages in thread
From: Sven Wischnowsky @ 2000-04-04 9:49 UTC (permalink / raw)
To: zsh-workers
Peter Stephenson wrote:
> ...
>
> Tail-ender: this is a real bug:
> % zsh -f
> % autoload -U compinit; compinit -D
> % zstyle ':completion:*' completer _expand _complete
> % zstyle ':<TAB>
> ^this gets replaced by an character from the upper end of
> ISO-8859-1 which I didn't particularly want to see.
We need to copy the quoted prefix/suffix when putting them into the
cline.
I've update the ChangeLog for the stuff from yesterday... but rcs2log
is completely unusable for me because it takes ages (so long that I
haven't let it run until the end). Is there a tool to get a ChangeLog
entry template from a diff? Or do I have to write that myself?
Bye
Sven
Index: Src/Zle/compcore.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compcore.c,v
retrieving revision 1.2
diff -u -r1.2 compcore.c
--- Src/Zle/compcore.c 2000/04/01 20:49:48 1.2
+++ Src/Zle/compcore.c 2000/04/04 09:42:00
@@ -1982,7 +1982,7 @@
sl = tsl;
}
if (qisl) {
- Cline qsl = bld_parts(qisuf, qisl, qisl, NULL);
+ Cline qsl = bld_parts(dupstring(qisuf), qisl, qisl, NULL);
qsl->flags |= CLF_SUF;
qsl->suffix = qsl->prefix;
@@ -2065,7 +2065,7 @@
line = p;
}
if (qipl) {
- Cline lp, p = bld_parts(qipre, qipl, qipl, &lp);
+ Cline lp, p = bld_parts(dupstring(qipre), qipl, qipl, &lp);
lp->next = line;
line = p;
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Completion issues
@ 2000-04-03 15:25 Sven Wischnowsky
2000-04-05 18:30 ` Peter Stephenson
0 siblings, 1 reply; 8+ messages in thread
From: Sven Wischnowsky @ 2000-04-03 15:25 UTC (permalink / raw)
To: zsh-workers
Peter Stephenson wrote:
> ...
>
> I tried this:
> zstyle ':completion:*:*:-command-:*' tag-order \
> 'functions:-non-comp:non-completion\ functions *' functions
> zstyle ':completion:*:functions-non-comp' ignored-patterns '_*'
> pretty much what's in the manual, except with a name. Now listing
> completions for zfl gives me
> Completing non-completion functions
> zfls
> Completing shell function
> zfls
> Completing alias
> zfls
> Forget the last one; arguably you should only get the alias in this case,
> since that's what will actually run, but I can see that's a
> sophistication. It's a bit annoying that I get the same function, for the
> same tag, both with filtering and without. With a long list it's going to
> be worse. Have I missed something?
No, my fault. The patterns should be replaced only with the tags
offered which are not yet given directly in the same string (with or
without a label). I forgot to re-implement that when moving the stuff
from shell code to C.
> ...
>
> The only problem there is I don't really want to upset the
> global tag-order for what is really a local problem for one tag. So I
> replaced the first line with:
> zstyle ':completion:*:functions' tag-order functions:-non-comp
> This doesn't work, and I can understand why it wouldn't --- looking up a
> tag using a tag is distinctly odd. But the manual implies this works with
> options:
> zstyle ':completion:*:options' tag-order 'options:-long:long options
> options:-short:short options
> options:-single-letter:single letter options'
> (formatted here with a ghastly offset of some thirty characters but I
> suppose that's my problem).
Urgh. Of course that should have been only `:completion:*', without
the `options'.
> As a subsidiary question, what happened to the
> backslashes the manual claims are needed for the spaces in the names? More
> importantly, what the heck's going on? Apparently looking up the tag
> `options' will, after all, force a re-lookup with options split into three.
> As far as I can see, this example is the only thing in the manual which
> tells you one way or the other whether you can explicitly split up tags
> into sub-tags like this. I'm now distinctly confused. Explanation?
I copied that from the late tag-aliases style, which could be set for
single tags and got the aliases/labels in separate words -- then I
forgot to remove the `:options' and insert the backslashes.
Hm. Your `don't really want to upset the global tag-order for what is
really a local problem'... that's what I intended the tag-aliases
styles for. But then I thought tag-order is enough -- as in the
example from the manual (once it is corrected by the patch
below). This may look a bit ugly, but if your main concern is speed:
this is done in C now, so it really isn't that expensive.
Hm. Should we add a tag-labels style again (tested for every tag in
tag-order, gives labels to use for this tag in its value)? My main
reason for not liking this that much is the fact that it's in C now --
I wanted to avoid having style-lookups hidden in some C-function.
So the question is: move things in shell code again, and add
tag-labels or leave it as it is. Unless someone sees a way to combine
them, of course.
> I came across the same problem when trying to explain _next_label using the
> code in _mh. Looking at the code, which is this:
> if _wanted sequences; then
> while _next_label sequences expl sequence; do
> compadd "$expl[@]" $(mark $foldnam 2>/dev/null |
> awk -F: '{ print $1 }') &&
> ret=0
> compadd "$expl[@]" reply next cur prev first last all unseen && ret=0
> _files "$expl[@]" -W folddir -g '<->' && ret=0
> (( ret )) || return 0
> done
> I would expect the following to work:
> zstyle ':completion:*:sequences' tag-order sequences:-name sequences:-num
> zstlye ':completion:*:sequences-name' ignored-patterns '<->'
> zstyle ':completion:*:sequences-num' ignored-patterns '^<->'
> prefering named sequences to messages which are just numbers. But it
> doesn't. I noted that despite being inside the _wanted, _files is used
> instead of _path_files, so I thought maybe it was using the files tag, but
> assuming a split into `sequences' and `files' doesn't seem to work either.
> What's the right way of doing this?
The way you did, with the patch below. The problem was that _files
didn't make sure that the ignored patterns also used the ones given to
_files. Another problem was the `(( ret ) || ...'. That shouldn't be
inside the label-loop (after all, we are looping over the labels that
have to be tried at the same time). This was wrong in several
completion functions.
Note, however, that _next_tags currently isn't smart enough to get
switching from one label to the next right. Hm, I've got to think some
more about this...
> By the way, the example given in the manual of ignored-patterns and tag
> labels,
> zstyle ':completion:*:*:-command-:*' tag-order 'functions:-non-comp'
> zstyle ':completion:*:functions-non-comp' ignored-patterns '_*'
> (= in command position, prefer the `functions' tag but use it with the name
> functions-non-comp; anywhere you see that tag, exclude patterns matching
> `_*) isn't particularly good, since the issue only really arises in command
> position after you've typed a character, hence you really need
> correction/approximation to test this, and it's hard to think of an
> example. I've borrowed this from the manual until I or someone else can
> think of another clean, simple example.
`nohup <TAB>'. But I agree, that it's a bad example. In fact, I tried
to think of a better one when I wrote that.
> Another thing: I couldn't get matcher-list to work for a labelled
> completer, e.g. _complete:-extended. When I switched to matcher instead,
> it worked fine. This fit my preconception, when I eventually decided what
> that would have been, because I though matcher-list was decided once right
> at the start. However, the manual explicitly says that you can use
> matcher-list with labelled completers.
And it works for me:
zstyle ':completion:*' completer _complete:-foo
zstyle ':completion:*:complete-foo:*' matcher-list '' 'm:{a-z}={A-Z}'
Note how the name of the completer is changed for lookup.
> Tail-ender: this is a real bug:
> % zsh -f
> % autoload -U compinit; compinit -D
> % zstyle ':completion:*' completer _expand _complete
> % zstyle ':<TAB>
> ^this gets replaced by an character from the upper end of
> ISO-8859-1 which I didn't particularly want to see.
>
> The style subst-globs-only is several times referred to without the
> plural, which is particularly annoying in _zstyle, but also occurs in the
> doc. (No patch, since it's almost half past midnight and I like to eat
> this evening.)
No patch for this yet...
> This is probably known, but _next_tags doesn't work well with menu
> completion. Ideally, it should probably remove the current choice if the
> last command was a menu completion and replace it with the first choice
> from the list generated with the next tag.
> Also, the message at the top
> doesn't change; you still see `Completing TeX or LaTeX file' if you cycle
> through to completing directories. Maybe this is a feature.
That's because the default for the file-patterns style doesn't add
descriptions, so the one given by the calling function is used. I has
always been like that. But I agree that it's particularly irritating
wiht _next_tags.
Bye
Sven
Index: Completion/Core/_files
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/_files,v
retrieving revision 1.2
diff -u -r1.2 _files
--- Completion/Core/_files 2000/04/01 20:43:43 1.2
+++ Completion/Core/_files 2000/04/03 15:25:30
@@ -1,12 +1,23 @@
#autoload
-local opts tmp glob pats expl tag i pat descr minus
+local opts tmp glob pats expl tag i pat descr end ign ret=1
zparseopts -a opts \
'/=tmp' 'f=tmp' 'g+:-=tmp' q n 1 2 P: S: r: R: W: X+: M+: F: J+: V+:
type="${(@j::M)${(@)tmp#-}#?}"
(( $tmp[(I)-g*] )) && glob="${(j: :)${(M)tmp:#-g*}#-g}"
+ign=$opts[(I)-F]
+if (( ign )); then
+ ign=( $=opts[ign+1] )
+ if [[ $ign = _comp_ignore ]]; then
+ ign=( $_comp_ignore )
+ else
+ opts[tmp+1]=_comp_ignore
+ fi
+else
+ ign=
+fi
if zstyle -a ":completion:${curcontext}:" file-patterns pats; then
[[ "$type" = */* ]] && glob="$glob *(-/)"
@@ -34,16 +45,24 @@
if [[ i -gt 0 && "$pat" != \ # ]]; then
if [[ "$pats[i]" = *:${tag}:* ]]; then
descr="${pats[i]#*:${tag}:}"
- minus=()
else
descr=file
- minus=(-)
+ end=yes
fi
fi
-
- _wanted "$tag" expl "$descr" \
- _path_files -g "$pat" "$opts[@]" "$minus[@]" && return 0
+ if _wanted "$tag"; then
+ _comp_ignore=()
+ while _next_label "$tag" expl "$descr"; do
+ _comp_ignore=( $_comp_ignored $ign )
+ if [[ -n "$end" ]]; then
+ _path_files -g "$pat" "$opts[@]" "$expl[@]" && ret=0
+ else
+ _path_files "$expl[@]" -g "$pat" "$opts[@]" && ret=0
+ fi
+ done
+ (( ret )) || return 0
+ fi
done
return 1
Index: Completion/User/_gdb
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/User/_gdb,v
retrieving revision 1.2
diff -u -r1.2 _gdb
--- Completion/User/_gdb 2000/04/01 20:43:43 1.2
+++ Completion/User/_gdb 2000/04/03 15:25:30
@@ -23,8 +23,8 @@
-directory\= -cd\= -tty\= && ret=0
compadd "$expl[@]" - -help -h -s -e -c -x -d -nx -n -quiet -q \
-batch -fullname -f -b && ret=0
- (( ret )) || return 0
done
+ (( ret )) || return 0
fi
else
prev="$words[CURRENT-1]"
Index: Completion/User/_getconf
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/User/_getconf,v
retrieving revision 1.2
diff -u -r1.2 _getconf
--- Completion/User/_getconf 2000/04/01 20:43:43 1.2
+++ Completion/User/_getconf 2000/04/03 15:25:30
@@ -29,7 +29,6 @@
_POSIX_NO_TRUNC _POSIX_VDISABLE && ret=0
compadd "$expl[@]" -S ' ' LINK_MAX MAX_CANON MAX_INPUT NAME_MAX \
PATH_MAX PIPE_BUF && ret=0
- (( ret )) || break
done
(( ret )) || return 0
done
Index: Completion/User/_mh
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/User/_mh,v
retrieving revision 1.2
diff -u -r1.2 _mh
--- Completion/User/_mh 2000/04/01 20:43:43 1.2
+++ Completion/User/_mh 2000/04/03 15:25:30
@@ -78,7 +78,6 @@
ret=0
compadd "$expl[@]" reply next cur prev first last all unseen && ret=0
_files "$expl[@]" -W folddir -g '<->' && ret=0
- (( ret )) || return 0
done
fi
return ret
Index: Completion/User/_netscape
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/User/_netscape,v
retrieving revision 1.2
diff -u -r1.2 _netscape
--- Completion/User/_netscape 2000/04/01 20:43:43 1.2
+++ Completion/User/_netscape 2000/04/03 15:25:30
@@ -82,7 +82,6 @@
while _next_label prefixes expl 'URL prefix'; do
compadd "$expl[@]" -S '' about: mocha: javascript: && ret=0
_urls "$@" && ret=0
- (( ret )) || return 0
done
fi
fi
Index: Completion/User/_tiff
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/User/_tiff,v
retrieving revision 1.2
diff -u -r1.2 _tiff
--- Completion/User/_tiff 2000/04/01 20:43:43 1.2
+++ Completion/User/_tiff 2000/04/03 15:25:30
@@ -199,7 +199,6 @@
while _next_label values expl 'compression scheme'; do
compadd "$expl[@]" - none g4 packbits && ret=0
compadd "$expl[@]" -qS: - lzw zip jpeg g3 && ret=0
- (( ret )) || return 0
done
fi
fi
Index: Completion/User/_urls
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/User/_urls,v
retrieving revision 1.2
diff -u -r1.2 _urls
--- Completion/User/_urls 2000/04/01 20:43:43 1.2
+++ Completion/User/_urls 2000/04/03 15:25:30
@@ -59,7 +59,6 @@
[[ -d $urls_path/bookmark ]] &&
compadd "$expl[@]" -S '' bookmark: && ret=0
compadd "$expl[@]" -S '' file: ftp:// gopher:// http:// && ret=0
- (( ret )) || return 0
done
return ret
fi
@@ -83,7 +82,6 @@
elif [[ -z "$PREFIX" ]]; then
compadd "$expl[@]" -S '/' -r '/' - "${PWD%/}" && ret=0
fi
- (( ret )) || return 0
done
return ret
fi
@@ -100,7 +98,6 @@
_path_files -W "$urls_path/$scheme" "$expl[@]" -S '' -g '*(^/)' &&
ret=0
_path_files -W "$urls_path/$scheme" -S/ -r '/' -/ && ret=0
- (( ret )) || return 0
done
fi
fi
@@ -116,7 +113,6 @@
(( $#uhosts )) || _hosts -S/ && ret=0
[[ "$scheme" = http ]] && uhosts=($uhosts $localhttp_servername)
compadd "$expl[@]" -S/ - $uhosts && ret=0
- (( ret )) || return 0
done
return ret
fi
@@ -136,20 +132,17 @@
while _next_label files expl 'local file'; do
_path_files "$expl[@]" -W ~$user/$localhttp_userdir -g '*(^/)' && ret=0
_path_files "$expl[@]" -W ~$user/$localhttp_userdir -S/ -r '/' -/ && ret=0
- (( ret )) || return 0
done
else
while _next_label files expl 'local file'; do
_path_files "$expl[@]" -W $localhttp_documentroot -g '*(^/)' && ret=0
_path_files "$expl[@]" -W $localhttp_documentroot -S/ -r '/' -/ && ret=0
- (( ret )) || return 0
done
fi
else
while _next_label files expl 'local file'; do
_path_files "$expl[@]" -W $urls_path/$scheme/$host -g '*(^/)' && ret=0
_path_files "$expl[@]" -W $urls_path/$scheme/$host -S/ -r '/' -/ && ret=0
- (( ret )) || return 0
done
fi
return $ret
Index: Completion/X/_xmodmap
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/X/_xmodmap,v
retrieving revision 1.2
diff -u -r1.2 _xmodmap
--- Completion/X/_xmodmap 2000/04/01 20:43:43 1.2
+++ Completion/X/_xmodmap 2000/04/03 15:25:30
@@ -86,7 +86,6 @@
while _next_label commands expl command; do
compadd "$expl[@]" -S ' ' keycode keysym clear add remove && ret=0
compadd "$expl[@]" -S ' = ' pointer && ret=0
- (( ret )) || return 0
done
fi
fi
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.4
diff -u -r1.4 compsys.yo
--- Doc/Zsh/compsys.yo 2000/04/03 13:13:02 1.4
+++ Doc/Zsh/compsys.yo 2000/04/03 15:25:31
@@ -1651,10 +1651,10 @@
Of course, this can also be used to split the matches for one tag into
different groups. For example:
-example(zstyle ':completion:*:options' tag-order \
- 'options:-long:long options
- options:-short:short options
- options:-single-letter:single letter options'
+example(zstyle ':completion:*' tag-order \
+ 'options:-long:long\ options
+ options:-short:short\ options
+ options:-single-letter:single\ letter\ options'
zstyle ':completion:*:options-long' ignored-patterns '[-+](|-|[^-]*)'
zstyle ':completion:*:options-short' ignored-patterns '--*' '[-+]?'
Index: Src/Zle/computil.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/computil.c,v
retrieving revision 1.2
diff -u -r1.2 computil.c
--- Src/Zle/computil.c 2000/04/01 20:49:48 1.2
+++ Src/Zle/computil.c 2000/04/03 15:25:32
@@ -2405,7 +2405,7 @@
while (*s) {
while (*s && iblank(*s))
s++;
- for (p = q = s, c = NULL; *s && !iblank(*s); s++) {
+ for (p = q = s, c = NULL; *s && !inblank(*s); s++) {
if (!c && *s == ':')
c = p;
if (*s == '\\' && s[1])
@@ -2423,12 +2423,26 @@
tokenize(qq);
if (haswilds(qq)) {
Patprog prog;
+ LinkNode node;
if ((prog = patcompile(qq, PAT_STATIC, NULL))) {
char **a, *n;
int l = (c ? strlen(c + 1) + 2 : 1), al;
for (a = all; *a; a++) {
+ for (node = firstnode(list); node;
+ incnode(node)) {
+ char *as, *ls;
+
+ for (as = *a, ls = (char *) getdata(node);
+ *as && *ls && *ls != ':'; as++, ls++)
+ if (*as != *ls)
+ break;
+ if (!*as && (!*ls || *ls == ':'))
+ break;
+ }
+ if (node)
+ continue;
if (pattry(prog, *a)) {
n = (char *) zhalloc((al = strlen(*a)) + l);
strcpy(n, *a);
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Completion issues
@ 2000-04-03 13:11 Sven Wischnowsky
0 siblings, 0 replies; 8+ messages in thread
From: Sven Wischnowsky @ 2000-04-03 13:11 UTC (permalink / raw)
To: zsh-workers
Bart Schaefer wrote:
> On Apr 1, 9:26pm, Peter Stephenson wrote:
> ...
>
> } Second, if I understood correctly, the default behaviour for completion is
> } to ignore ignored completions completely. Thus the behaviour of $fignore
> } has changed.
>
> Unless I'm getting the wrong version of a function, it appears that this
> is special-cased by _path_files so that $fignore has not changed -- but
> if you use the ignored-patterns style instead, then ignored completions
> really are ignored, and you need to add the _ignored completer to get
> the old behavior back.
No, $fignore is used in the same way as ignored-patterns (and ignored
only by _ignored).
So, this changes the default for the completer style.
Bye
Sven
Index: Completion/Core/_main_complete
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/_main_complete,v
retrieving revision 1.2
diff -u -r1.2 _main_complete
--- Completion/Core/_main_complete 2000/04/01 20:43:43 1.2
+++ Completion/Core/_main_complete 2000/04/03 13:07:22
@@ -62,7 +62,7 @@
_completers=( "$@" )
else
zstyle -a ":completion:${curcontext}:" completer _completers ||
- _completers=( _complete )
+ _completers=( _complete _ignored )
fi
# And now just call the completer functions defined.
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.3
diff -u -r1.3 compsys.yo
--- Doc/Zsh/compsys.yo 2000/04/03 12:56:31 1.3
+++ Doc/Zsh/compsys.yo 2000/04/03 13:07:25
@@ -841,8 +841,10 @@
zstyle ':completion:incremental:*' completer _complete _correct
zstyle ':completion:predict:*' completer _complete)
-The default value for this style is tt(_complete), i.e. normally only
-completion will be done.
+The default value for this style is tt(_complete _ignored),
+i.e. normally only completion will be done, first using the
+tt(ignored-patterns) style and the tt($fignore) array and then without
+ignoring matches because of these.
)
kindex(completions, completion style)
item(tt(completions))(
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Completion issues
@ 2000-04-03 12:56 Sven Wischnowsky
0 siblings, 0 replies; 8+ messages in thread
From: Sven Wischnowsky @ 2000-04-03 12:56 UTC (permalink / raw)
To: zsh-workers
Bart Schaefer wrote:
> On Apr 1, 9:26pm, Peter Stephenson wrote:
> } Subject: Completion issues
> }
> } First, I hate the new behaviour of _complete_help. I use it to find out
> } what context I'm in. Unfortunately I don't get to see that, because a huge
> } list of style has scrolled by.
>
> I won't say I *hate* the new behavior, but I was certainly alarmed by the
> amount of style output that was generated even for something like "ls" or
> "echo" that doesn't have any special handling. "cvs <^Xh>" is horrifying.
> That list-colors, list-packed, list-rows-first, last-prompt, accept-exact,
> and menu appear no less than 8 times each seems a tad excessive.
I get them only three times -- it all depends on ones setup...
> } I don't think a style to turn off styles in ^Xh is good enough,
> } there's too much mucking around, and you may want the style information
> } anyway. A workable alternative is that a numeric argument activates the
> } style list --- this feature could be configurable by a style.
>
> I like the numeric-argument idea. If we wanted to get really fancy, a
> number from 1-4 could denote increasingly verbose output, so that using
> universal-argument would produce the full-blown listing.
>
> I'm not convinced we'd need a style to make that configurable, though.
> It's pretty straightforward to create a zle widget that sets NUMERIC and
> then calls another widget.
Ok. The patch makes the style list be shown only if _complete_help is
given a numeric argument.
I haven't tried to make this support multiple levels of verboseness
yet. The only probelm I have with that is to decide what to show on
the intermediate levels, though. I mean, for example, showing the
styles used without the contexts in which they are used can be both
misleading and useless. In some cases. I think. Hm.
Bye
Sven
Index: Completion/Commands/_complete_help
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Commands/_complete_help,v
retrieving revision 1.2
diff -u -r1.2 _complete_help
--- Completion/Commands/_complete_help 2000/04/01 20:43:43 1.2
+++ Completion/Commands/_complete_help 2000/04/03 12:50:02
@@ -44,21 +44,22 @@
text="${text}${tmp}"
done
- text="$text
+ if [[ ${NUMERIC:-1} -ne 1 ]]; then
+ text="$text
"
- for i in "${(@ok)help_sfuncs}"; do
- text="${text}
+ for i in "${(@ok)help_sfuncs}"; do
+ text="${text}
styles in context ${i}"
- tmp=()
- for j in "${(@s.:.)help_sfuncs[$i][2,-1]}"; do
- tmp=( "$tmp[@]" "${(@s.,.)help_styles[${i}${j}][2,-1]}" )
- done
- zformat -a tmp ' (' "$tmp[@]"
- tmp=( '
+ tmp=()
+ for j in "${(@s.:.)help_sfuncs[$i][2,-1]}"; do
+ tmp=( "$tmp[@]" "${(@s.,.)help_styles[${i}${j}][2,-1]}" )
+ done
+ zformat -a tmp ' (' "$tmp[@]"
+ tmp=( '
'${^tmp}')' )
- text="${text}${tmp}"
- done
-
+ text="${text}${tmp}"
+ done
+ fi
compstate[list]='list force'
compstate[insert]=''
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.2
diff -u -r1.2 compsys.yo
--- Doc/Zsh/compsys.yo 2000/04/01 20:43:44 1.2
+++ Doc/Zsh/compsys.yo 2000/04/03 12:50:05
@@ -355,8 +355,7 @@
ifnzman(noderef(Bindable Commands))
can be invoked to find out the context and tag names and styles used at a particular
point in completion. It shows a list of context names and the
-tag names used in those contexts and then a list of context names and
-the styles used in those contexts if completion were tried at the
+tag names used in those contexts if completion were tried at the
current cursor position. Hence one can easily find out all the
information needed to change the behaviour of the tt(tag-order) style
for a particular context.
@@ -2200,8 +2199,10 @@
findex(_complete_help (^Xh))
item(tt(_complete_help (^Xh)))(
This widget displays information about the context names,
-the tags, the styles, and the completion functions used
-when completing at the current cursor position.
+the tags, and the completion functions used
+when completing at the current cursor position. If given a numeric
+argument other than tt(1) (as in `tt(ESC-2 ^Xh)'), then the styles
+used and the contexts for which they are used will be shown, too.
Note that, depending on the control flow in the completion functions
called, the information about the styles may be
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2000-04-06 7:31 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-01 20:26 Completion issues Peter Stephenson
2000-04-02 3:16 ` Bart Schaefer
2000-04-03 12:56 Sven Wischnowsky
2000-04-03 13:11 Sven Wischnowsky
2000-04-03 15:25 Sven Wischnowsky
2000-04-05 18:30 ` Peter Stephenson
2000-04-04 9:49 Sven Wischnowsky
2000-04-06 7:31 Sven Wischnowsky
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).