* problem with _arguments exclusion lists @ 2001-04-12 14:32 Oliver Kiddle 2001-04-17 9:50 ` Sven Wischnowsky 0 siblings, 1 reply; 18+ messages in thread From: Oliver Kiddle @ 2001-04-12 14:32 UTC (permalink / raw) To: zsh-workers The following doesn't work too well: _arguments -s '(-conf)-c' '-conf' '-f' when you try to complete directly after `-c'. It should still allow the -conf option because the c could be the c from conf and not the -c option. This means that completing the -conf option isn't possible. Oliver ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: problem with _arguments exclusion lists 2001-04-12 14:32 problem with _arguments exclusion lists Oliver Kiddle @ 2001-04-17 9:50 ` Sven Wischnowsky 2001-04-17 10:44 ` Oliver Kiddle 0 siblings, 1 reply; 18+ messages in thread From: Sven Wischnowsky @ 2001-04-17 9:50 UTC (permalink / raw) To: zsh-workers Oliver Kiddle wrote: > The following doesn't work too well: > _arguments -s '(-conf)-c' '-conf' '-f' > when you try to complete directly after `-c'. It should still allow the > -conf option because the c could be the c from conf and not the -c > option. This means that completing the -conf option isn't possible. Hrmpf. Yes. This was a bit more complicated to fix because the option should still keep itself from being offered as a possible completion a second time unless it may be given more than once. Bye Sven Index: Src/Zle/computil.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/computil.c,v retrieving revision 1.47 diff -u -r1.47 computil.c --- Src/Zle/computil.c 2001/04/02 09:05:50 1.47 +++ Src/Zle/computil.c 2001/04/17 09:49:17 @@ -1145,7 +1145,7 @@ static LinkList ca_xor; static int -ca_inactive(Cadef d, char **xor, int cur, int opts) +ca_inactive(Cadef d, char **xor, int cur, int opts, char *optname) { if ((xor || opts) && cur <= compcurrent) { Caopt opt; @@ -1153,6 +1153,8 @@ int sl = (d->set ? strlen(d->set) : -1), set = 0; for (; (x = (opts ? "-" : *xor)); xor++) { + if (optname && strcmp(optname, x)) + continue; if (ca_xor) addlinknode(ca_xor, x); set = 0; @@ -1315,9 +1317,9 @@ dopt = NULL; doff = state.singles = arglast = 0; - if (ca_inactive(d, argxor, cur, 0) || + if (ca_inactive(d, argxor, cur, 0, NULL) || ((d->flags & CDF_SEP) && cur != compcurrent && !strcmp(line, "--"))) { - if (ca_inactive(d, NULL, cur, 1)) + if (ca_inactive(d, NULL, cur, 1, NULL)) return 1; continue; } @@ -1391,7 +1393,7 @@ if (!state.oargs[state.curopt->num]) state.oargs[state.curopt->num] = znewlinklist(); - if (ca_inactive(d, state.curopt->xor, cur, 0)) + if (ca_inactive(d, state.curopt->xor, cur, 0, state.curopt->name)) return 1; /* Collect the argument strings. Maybe. */ @@ -1444,7 +1446,7 @@ if (!state.oargs[tmpopt->num]) state.oargs[tmpopt->num] = znewlinklist(); - if (ca_inactive(d, tmpopt->xor, cur, 0)) + if (ca_inactive(d, tmpopt->xor, cur, 0, tmpopt->name)) return 1; } } @@ -1476,7 +1478,7 @@ return 1; else if (state.arg && (!napat || !pattry(napat, line))) { /* Otherwise it's a normal argument. */ - if (napat && ca_inactive(d, NULL, cur + 1, 1)) + if (napat && ca_inactive(d, NULL, cur + 1, 1, NULL)) return 1; arglast = 1; @@ -1791,7 +1793,7 @@ for (node = firstnode(nx); node; incnode(node)) { xor[0] = (char *) getdata(node); if (!strcmp(xor[0], def->sname) || - ca_inactive(def, xor, compcurrent, 0)) + ca_inactive(def, xor, compcurrent, 0, NULL)) break; } if (!node) -- Sven Wischnowsky wischnow@informatik.hu-berlin.de ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: problem with _arguments exclusion lists 2001-04-17 9:50 ` Sven Wischnowsky @ 2001-04-17 10:44 ` Oliver Kiddle 2001-04-17 11:28 ` Sven Wischnowsky 0 siblings, 1 reply; 18+ messages in thread From: Oliver Kiddle @ 2001-04-17 10:44 UTC (permalink / raw) To: zsh-workers --- Sven Wischnowsky <wischnow@informatik.hu-berlin.de> wrote: > Hrmpf. Yes. This was a bit more complicated to fix because the option > should still keep itself from being offered as a possible completion > a > second time unless it may be given more than once. I suspected that it mightn't be too easy when I posted the first message. The patch seems to fix it but the following still doesn't work: _arguments -s '(-conf)-c+:val' '-conf' '-f' after -c, it completes with the 'val' message so even after -co, it can't complete -conf. I found these problems with _pine which completes a number after -c. Maybe there would be a use here for a basic completion for numbers so that it can know that -co can not be -c with a parameter. Oliver ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: problem with _arguments exclusion lists 2001-04-17 10:44 ` Oliver Kiddle @ 2001-04-17 11:28 ` Sven Wischnowsky 2001-04-17 13:55 ` Oliver Kiddle 0 siblings, 1 reply; 18+ messages in thread From: Sven Wischnowsky @ 2001-04-17 11:28 UTC (permalink / raw) To: zsh-workers Oliver Kiddle wrote: > --- Sven Wischnowsky <wischnow@informatik.hu-berlin.de> wrote: > > > Hrmpf. Yes. This was a bit more complicated to fix because the option > > should still keep itself from being offered as a possible completion > > a > > second time unless it may be given more than once. > > I suspected that it mightn't be too easy when I posted the first > message. The patch seems to fix it but the following still doesn't > work: > _arguments -s '(-conf)-c+:val' '-conf' '-f' > after -c, it completes with the 'val' message so even after -co, it > can't complete -conf. I found these problems with _pine which completes > a number after -c. Maybe there would be a use here for a basic > completion for numbers so that it can know that -co can not be -c with > a parameter. Yes, i was aware of that. The problem is that some programs would not continue parsing `-c...' as a possible option, while some would. I think I would call such programs `well-behaved'. I also seem to remember that we discussed this many months ago, but don't know what we said about all this then. It seems doable to add another option to _arguments telling it that even after such an option other options should be completed. Would that have to include options described as `-c-:...'? Or do we even have to allow specifying that on a per-option basis, i.e. add yet another special character that may be given after the option name to say that there is an argument to be completed directly after the option, but other options might come, too? Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: problem with _arguments exclusion lists 2001-04-17 11:28 ` Sven Wischnowsky @ 2001-04-17 13:55 ` Oliver Kiddle 2001-04-17 14:10 ` Sven Wischnowsky 0 siblings, 1 reply; 18+ messages in thread From: Oliver Kiddle @ 2001-04-17 13:55 UTC (permalink / raw) To: zsh-workers --- Sven Wischnowsky <wischnow@informatik.hu-berlin.de> wrote: > > _arguments -s '(-conf)-c+:val' '-conf' '-f' > > after -c, it completes with the 'val' message so even after -co, it > > can't complete -conf. I found these problems with _pine which > > completes a number after -c. > Yes, i was aware of that. The problem is that some programs would > not > continue parsing `-c...' as a possible option, while some would. I > think I would call such programs `well-behaved'. I think you've misunderstood me here. Are you thinking of the case where, for the _arguments example above some programs maybe allow the `f' option after -c as `-cf3' to mean the same as `-c3 -f'? In a case such as _pine, after `-c', there can either be a number which is an argument to the -c option or it could go on to complete an option with a longer name such as -conf, -character-set etc. At the moment, it fails to complete the latter and it should do. This was the intended gist of my last message. > > Maybe there would be a use here for a basic > > completion for numbers so that it can know that -co can not be -c > with > > a parameter. What I was basically getting at there is something along the lines of [[ $PREFIX$SUFFIX = [0-9]* ]] && _message 'number' so that after -co, it could see that the `o' doesn't match [0-9]* and would only complete further options (such as -conf). Oliver ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: problem with _arguments exclusion lists 2001-04-17 13:55 ` Oliver Kiddle @ 2001-04-17 14:10 ` Sven Wischnowsky 2001-04-19 14:01 ` Oliver Kiddle 0 siblings, 1 reply; 18+ messages in thread From: Sven Wischnowsky @ 2001-04-17 14:10 UTC (permalink / raw) To: zsh-workers Oliver Kiddle wrote: > ... > > What I was basically getting at there is something along the lines of > [[ $PREFIX$SUFFIX = [0-9]* ]] && _message 'number' > so that after -co, it could see that the `o' doesn't match [0-9]* and > would only complete further options (such as -conf). ;-) I understood you, really. But I'm pretty sure there are programs that allow other (single letter) options after that `-c', meaning that either `-c's argument is the empty string or that it comes in the next word. Or something. So I still think we need a way to tell _arguments that either: 1) after all `-x-:...' or `-x+:...' options other options may be completed, or 2) that after some of those options other options may be completed, or 3) (what you described) that the argument of option `-x+:...' has to match a certain pattern and if it doesn't match, other options are to be completed there. All that is independent of what we choose to use as the default. I.e., if we leave the current behaviour the default or if we make completing options there the default (unless otherwise specified). Or maybe I'm thinking way to complicated again and we should just make it try completing options in such places, too. If the user has already started typing the argument of the option, other option names won't match anyway. Leaves only the slight ugliness that `-c<TAB>' would offer other single-letter options as possible completions (if _arguments was given the -s options), even if the command doesn't allow that after options that get an argument. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: problem with _arguments exclusion lists 2001-04-17 14:10 ` Sven Wischnowsky @ 2001-04-19 14:01 ` Oliver Kiddle 2001-04-20 8:31 ` Sven Wischnowsky 0 siblings, 1 reply; 18+ messages in thread From: Oliver Kiddle @ 2001-04-19 14:01 UTC (permalink / raw) To: zsh-workers Sven Wischnowsky wrote: > > ;-) I understood you, really. But I'm pretty sure there are programs > that allow other (single letter) options after that `-c', meaning that > either `-c's argument is the empty string or that it comes in the next > word. Or something. So I still think we need a way to tell _arguments > that either: > > 1) after all `-x-:...' or `-x+:...' options other options may be > completed, or I suppose this option would involve another option to _arguments like -W and it would only be useful with -s. > 2) that after some of those options other options may be completed, or And, I suppose this would handle commands which are inconsistent in the way they behave for different options. For the _arguments syntax, I can't think of much better than some additional random character before the colon. I suppose that of these (2) covers more possible situations so is the most complete but we could have both where the option (as per (1)) specifies a default and the syntax for (2) overrides it. Keeping this in mind, if (1) is implemented, (2) could be added later if we find inconsistent commands for which it is needed. > All that is independent of what we choose to use as the default. I.e., > if we leave the current behaviour the default or if we make completing > options there the default (unless otherwise specified). I would probably vote for the current behaviour being the default - that is not completing other options in this case because it is probably more common for commands to parse arguments that way and it keeps the number of matches down. > Or maybe I'm thinking way to complicated again and we should just make > it try completing options in such places, too. If the user has already Possibly, but I would err on the side of making it not try completing options in such places. When I type commands, I tend to specify them in a clear sensible way rather than the most minimal way that command happens to allow. > started typing the argument of the option, other option names won't > match anyway. True. And if other option names do match, the user might be trying to complete the option name so it is important that it is added as a match. > Leaves only the slight ugliness that `-c<TAB>' would > offer other single-letter options as possible completions (if _arguments > was given the -s options), even if the command doesn't allow that after > options that get an argument. That is really quite ugly and backs up my feeling that this should not be the default. > 3) (what you described) that the argument of option `-x+:...' has to > match a certain pattern and if it doesn't match, other options are to > be completed there. I think it is a good idea to maybe complete options only if we fail to complete the option argument because it avoids the ugliness mentioned above. Would it be possible to use a tag-order style to put the options last here? I wouldn't want to put the pattern in _arguments though. What follows is a separate issue really so is a bit of a divergence. As a test, I created an _number like this: [[ $PREFIX$SUFFIX = [0-9]# ]] || return 1 _message 'number' && return 0 And then used this _arguments: _arguments -s '-c+:number:_number' '-conf' Now, if I complete after -co, I get the message: No matches for: `number' or `corrections' What _arguments should do in this case is see the return code from _number and from it conclude that we are not completing a parameter to -c because it failed. For (3), it could then complete other single letter options (it should be adding -conf as a match regardless). This may be more complicated but is how I think we should be specifying patterns if we use option (3). Incidentally, with this when completing after just -c, the message `number' is displayed to indicate that what is expected is a number. It does not look up the format style with the descriptions tag and display it in bold (with my style settings). I think it should because `number' is a group of matches the same as other things we complete (option, user etc), it is just that we haven't generated as matches all possible numbers. We could have a general function which is called like _message to say we are completing such and such sort of thing but are not adding the actual matches because it doesn't make sense to. It could take an option for specifying a pattern to compare against $PREFIX/$SUFFIX to allow it to fail when appropriate. Oliver ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: problem with _arguments exclusion lists 2001-04-19 14:01 ` Oliver Kiddle @ 2001-04-20 8:31 ` Sven Wischnowsky 2001-04-23 8:59 ` Oliver Kiddle 0 siblings, 1 reply; 18+ messages in thread From: Sven Wischnowsky @ 2001-04-20 8:31 UTC (permalink / raw) To: zsh-workers Let me try to summarise: 1) Add an option to _arguments, that says that it should always try to complete options after options specified with `-x-:...' or `-x+:...'. This makes it a stronger form of -W: -W makes it complete options after options that get an argument in the next word. The new option says that other options are to be completed even if the argument has to or may be given in the same word. 2) Also, make it try completing options in those places even if the new _arguments-option is not given but the action for the argument returns non-null. The `returns non-null' is, of course, problematic again if the option- argument has to be completed with a `->state' action. But I think if a command is complicated enough to require that, it should use the option from 1) anyway. And add a small utility function that can be put into an argument- action and tests if the string typed so far matches some pattern. For simplicity I would make it use the description given in the _arguments-spec. And if a simple pattern match is enough for most cases, this makes it sound as if we should just add a new action- syntax, avoiding the need for an extra function consisting of only two lines. More complicated tests can still be implemented with additional functions, of course. I don't remember exactly, but I think we were talking about pattern matching in _arguments-actions some time ago. If we decide to put the simple matching-case into _arguments itself, we could also go another way: instead of making it a new type of action, we make it be some kind of `guard' that can be prefixed to any of the action-types _arguments supports now. If it is given before an empty option, it only says if a message should be displayed or not. I think I like this even better. Ok, would this be enough for now? Later we can, as suggested by Oliver, add a way to change the behaviour on a per-option basis, using the option from 1) as the default. If we ever meet a command that needs that much control. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: problem with _arguments exclusion lists 2001-04-20 8:31 ` Sven Wischnowsky @ 2001-04-23 8:59 ` Oliver Kiddle 2001-04-24 10:00 ` Sven Wischnowsky 2001-04-25 7:10 ` Sven Wischnowsky 0 siblings, 2 replies; 18+ messages in thread From: Oliver Kiddle @ 2001-04-23 8:59 UTC (permalink / raw) To: zsh-workers Sven Wischnowsky wrote: > > 1) Add an option to _arguments, that says that it should always try to > complete options after options specified with `-x-:...' or `-x+:...'. > 2) Also, make it try completing options in those places even if the new > _arguments-option is not given but the action for the argument > returns non-null. I'm happy with that. > The `returns non-null' is, of course, problematic again if the option- > argument has to be completed with a `->state' action. But I think if That's a bit of a pity. > And add a small utility function that can be put into an argument- > action and tests if the string typed so far matches some pattern. Agreed. > For simplicity I would make it use the description given in the > _arguments-spec. I'll be interested to see how you do that. I think the function will have wider uses than just from _arguments such as from _alternative so it would be good if it can cope with that. > And if a simple pattern match is enough for most > cases, this makes it sound as if we should just add a new action- > syntax, avoiding the need for an extra function consisting of only I prefer the extra two-line function to extending _arguments' action spec syntax. The function is a more general method which may be more widely useful and it keeps things more in zsh shell syntax than in _arguments syntax. Also, I can't see that guards on _arguments specs would be particularly useful when matches are generated. > Ok, would this be enough for now? Later we can, as suggested by Oliver, > add a way to change the behaviour on a per-option basis, using the > option from 1) as the default. If we ever meet a command that needs > that much control. Agreed. Oliver ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: problem with _arguments exclusion lists 2001-04-23 8:59 ` Oliver Kiddle @ 2001-04-24 10:00 ` Sven Wischnowsky 2001-04-26 11:00 ` Oliver Kiddle 2001-04-25 7:10 ` Sven Wischnowsky 1 sibling, 1 reply; 18+ messages in thread From: Sven Wischnowsky @ 2001-04-24 10:00 UTC (permalink / raw) To: zsh-workers Ok, here's my suggestion. The option's name is `-w', dunno if we should exchange the meaning of -W and -w (-w is the stronger one, so to say). Then I suggest to use the following as the pattern-match utility function: local mesg pat garbage mesg=() zparseopts -K -D -a garbage M: J: V: 1 2 n F: X:=mesg [[ "$PREFIX$SUFFIX" != $~1 ]] && return 1 if [[ $# -gt 1 || $#mesg -eq 0 ]]; then shift _message "$*" else _message -r "$mesg[2]" fi [[ -n "$PREFIX$SUFFIX" ]] It ignores the compadd-options that might be passed from the completion system internals to called function and can extract a given explanation string from that (e.g. when called from _arguments or _alternative). The first real argument is the pattern to test for and if more arguments are given, those are used as the description to display (overriding the string from -X, if any). It might be called as in: _arguments -s '(-conf)-c+:numeric value:prop "[0-9]#"' '-conf' '-f' or: _arguments -s '(-conf)-c+: :prop "[0-9]#" numeric value' '-conf' '-f' and makes that complete options and display the message after `-c<TAB>'. After `-c<digits><TAB>' only the message will be displayed and after `-c<non-digits><TAB>' only options will be completed. All that due to the new behaviour of completing options if the action returns non-zero. That feels quite satisfying. So, if anyway can tell me a good name for that utility function, I'm going to commit it. I really don't have the faintest idea. Oliver? Bye Sven Index: Completion/Base/Utility/_arguments =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_arguments,v retrieving revision 1.3 diff -u -r1.3 _arguments --- Completion/Base/Utility/_arguments 2001/04/05 12:12:47 1.3 +++ Completion/Base/Utility/_arguments 2001/04/24 09:59:46 @@ -4,7 +4,7 @@ # descriptions given as arguments to this function. local long cmd="$words[1]" descr mesg subopts opt usecc autod -local oldcontext="$curcontext" hasopts rawret optarg singopt +local oldcontext="$curcontext" hasopts rawret optarg singopt alwopt long=$argv[(I)--] if (( long )); then @@ -174,7 +174,7 @@ subopts=() singopt=() -while [[ "$1" = -(O*|[CRWs]) ]]; do +while [[ "$1" = -(O*|[CRWsw]) ]]; do case "$1" in -C) usecc=yes; shift ;; -O) subopts=( "${(@P)2}" ); shift 2 ;; @@ -182,13 +182,14 @@ -R) rawret=yes; shift;; -W) optarg=yes; shift;; -s) singopt=(-s); shift;; + -w) alwopt=yes; shift;; esac done zstyle -s ":completion:${curcontext}:options" auto-description autod if (( $# )) && comparguments -i "$autod" "$singopt[@]" "$@"; then - local action noargs aret expl local tried + local action noargs aret expl local tried ret=1 local next direct odirect equal single matcher matched ws tmp1 tmp2 tmp3 local opts subc tc prefix suffix descrs actions subcs anum local origpre="$PREFIX" origipre="$IPREFIX" nm="$compstate[nmatches]" @@ -280,7 +281,8 @@ eval ws\=\( "${action[3,-3]}" \) - _describe -t "$subc" "$descr" ws -M "$matcher" "$subopts[@]" + _describe -t "$subc" "$descr" ws -M "$matcher" "$subopts[@]" || + alwopt=yes tried=yes elif [[ "$action" = \(*\) ]]; then @@ -289,15 +291,17 @@ eval ws\=\( "${action[2,-2]}" \) - _all_labels "$subc" expl "$descr" compadd "$subopts[@]" -a - ws + _all_labels "$subc" expl "$descr" compadd "$subopts[@]" -a - ws || + alwopt=yes tried=yes elif [[ "$action" = \{*\} ]]; then # A string in braces is evaluated. while _next_label "$subc" expl "$descr"; do - eval "$action[2,-2]" + eval "$action[2,-2]" && ret=0 done + (( ret )) && alwopt=yes tried=yes elif [[ "$action" = \ * ]]; then @@ -305,8 +309,9 @@ eval "action=( $action )" while _next_label "$subc" expl "$descr"; do - "$action[@]" + "$action[@]" && ret=0 done + (( ret )) && alwopt=yes tried=yes else @@ -314,15 +319,17 @@ eval "action=( $action )" while _next_label "$subc" expl "$descr"; do - "$action[1]" "$subopts[@]" "$expl[@]" "${(@)action[2,-1]}" + "$action[1]" "$subopts[@]" "$expl[@]" "${(@)action[2,-1]}" && ret=0 done + (( ret )) && alwopt=yes tried=yes fi fi fi done - - if [[ -z "$matched$hasopts" && ( -z "$aret" || "$PREFIX" = "$origpre" ) ]] && + if [[ -z "$hasopts" && + ( -z "$matched" || -n "$alwopt" ) && + ( -z "$aret" || "$PREFIX" = "$origpre" ) ]] && _requested options && { ! zstyle -T ":completion:${curcontext}:options" prefix-needed || [[ "$origpre" = [-+]* || -z "$aret$mesg$tried" ]] } ; then @@ -378,9 +385,10 @@ PREFIX="$prevpre" IPREFIX="$previpre" fi - [[ -n "$tried" && "$PREFIX" != [-+]* ]] && break + [[ -n "$tried" && "${${alwopt:+$origpre}:-$PREFIX}" != [-+]* ]] && break done - if [[ -n "$opts" && -z "$aret$matched$mesg" && + if [[ -n "$opts" && -z "$aret" && + ( -z "$matched$mesg" || -n "$alwopt" ) && nm -eq compstate[nmatches] ]]; then PREFIX="$origpre" Index: Completion/X/Utility/_x_arguments =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/X/Utility/_x_arguments,v retrieving revision 1.2 diff -u -r1.2 _x_arguments --- Completion/X/Utility/_x_arguments 2001/04/04 11:29:22 1.2 +++ Completion/X/Utility/_x_arguments 2001/04/24 09:59:47 @@ -17,7 +17,7 @@ fi opts=() -while [[ $1 = -(O*|[CRWs]) ]]; do +while [[ $1 = -(O*|[CRWsw]) ]]; do opts=($opts $1) [[ $1 = -R ]] && rawret=yes shift Index: Completion/X/Utility/_xt_arguments =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/X/Utility/_xt_arguments,v retrieving revision 1.2 diff -u -r1.2 _xt_arguments --- Completion/X/Utility/_xt_arguments 2001/04/04 11:29:22 1.2 +++ Completion/X/Utility/_xt_arguments 2001/04/24 09:59:47 @@ -53,7 +53,7 @@ fi opts=() -while [[ $1 = -(O*|[CRWs]) ]]; do +while [[ $1 = -(O*|[CRWsw]) ]]; do opts=($opts $1) [[ $1 = -R ]] && rawret=yes shift Index: Doc/Zsh/compsys.yo =================================================================== RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v retrieving revision 1.117 diff -u -r1.117 compsys.yo --- Doc/Zsh/compsys.yo 2001/04/04 11:29:22 1.117 +++ Doc/Zsh/compsys.yo 2001/04/24 09:59:50 @@ -2937,6 +2937,18 @@ normally not complete the other option directly after `tt(-a)', but it would allow that if given the tt(-W) option. +Similarly, the option tt(-w) may be given to force completion of options +even after options that get an argument in the same word. For example, +if a command takes the options `tt(a)' and `tt(b)', where `tt(a)' needs +an argument in the same word, directly after the option character, +tt(_arguments) would normally only execute the action for that argument +and not offer other options as possible completions. If given the +tt(-w) option, it will offer other options as possible completions after +executing the action for the argument. Note that, depending on the +action, this may mean that the other options can't really be completed, +but at least they will be listed. For more control, use an utility +function like tt(_XXX) in the argument's action. + The forms of var(optspec) are: startitem() Index: Src/Zle/computil.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/computil.c,v retrieving revision 1.48 diff -u -r1.48 computil.c --- Src/Zle/computil.c 2001/04/17 09:52:32 1.48 +++ Src/Zle/computil.c 2001/04/24 09:59:51 @@ -1941,7 +1941,12 @@ case 's': for (; lstate; lstate = lstate->snext) if (lstate->d->single && lstate->singles && - lstate->actopts && lstate->opt) { + lstate->actopts +#if 0 + /* let's try without, for the -o option of _arguments */ + && lstate->opt +#endif + ) { setsparam(args[1], ztrdup((lstate->ddef && lstate->dopt) ? (lstate->dopt->type == CAO_DIRECT ? -- Sven Wischnowsky wischnow@informatik.hu-berlin.de ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: problem with _arguments exclusion lists 2001-04-24 10:00 ` Sven Wischnowsky @ 2001-04-26 11:00 ` Oliver Kiddle 2001-04-26 12:10 ` Sven Wischnowsky 0 siblings, 1 reply; 18+ messages in thread From: Oliver Kiddle @ 2001-04-26 11:00 UTC (permalink / raw) To: Sven Wischnowsky, zsh-workers --- Sven Wischnowsky <wischnow@informatik.hu-berlin.de> wrote: > Ok, here's my suggestion. The option's name is `-w', dunno if we > should > exchange the meaning of -W and -w (-w is the stronger one, so to > say). Yes, we probably should swap them. > Then I suggest to use the following as the pattern-match utility Looks good. I thought the description might be more complicated than just using -X. > [[ -n "$PREFIX$SUFFIX" ]] I'm not sure about this line at the end. It is not a likely option name but, using the usual example, this would prevent a -c0nf option being completed from -c0<tab>. In what sort of case did you see it as being useful? > It might be called as in: > _arguments -s '(-conf)-c+:numeric value:prop "[0-9]#"' '-conf' > '-f' Testing this, I get what I thought was -w behaviour only: -c<tab> offers: numeric value option -conf -f I thought that it was only going to offer -f if _arguments was passed the -w option. > That feels quite satisfying. It's great. Thanks Sven. > So, if anyway can tell me a good name for that utility function, I'm > going to commit it. I really don't have the faintest idea. Oliver? I didn't have much in mind. The best I can think of is _guard. I'd prefer something short because it will be most used in the generally long _arguments specs so I'm not too keen on something like _messsage_guarded. Other ideas are _block, _pattern, _failpat. Oliver ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: problem with _arguments exclusion lists 2001-04-26 11:00 ` Oliver Kiddle @ 2001-04-26 12:10 ` Sven Wischnowsky 0 siblings, 0 replies; 18+ messages in thread From: Sven Wischnowsky @ 2001-04-26 12:10 UTC (permalink / raw) To: zsh-workers Oliver Kiddle wrote: > ... > > > [[ -n "$PREFIX$SUFFIX" ]] > > I'm not sure about this line at the end. It is not a likely option name > but, using the usual example, this would prevent a -c0nf option being > completed from -c0<tab>. In what sort of case did you see it as being > useful? In the case you described next: If the word to complete is empty I want it to both display the message and complete options. I noticed that only when I had implemented (before, we were discussing only two cases: message *or* options). We could make that optional by giving _guard an option, but I'd still prefer this as the default behaviour. > > It might be called as in: > > _arguments -s '(-conf)-c+:numeric value:prop "[0-9]#"' '-conf' > > '-f' > > Testing this, I get what I thought was -w behaviour only: -c<tab> > offers: > numeric value > option > -conf -f > I thought that it was only going to offer -f if _arguments was passed > the -w option. No, -w (now -W since I swapped them), makes it complete options regardless of the return value of the action. What you're seeing here is the new default behaviour of trying to complete options if the action returns non-zero. > ... > > I didn't have much in mind. The best I can think of is _guard. I'd > prefer something short because it will be most used in the generally > long _arguments specs so I'm not too keen on something like > _messsage_guarded. Other ideas are _block, _pattern, _failpat. I was hoping for something short, but still alluding to `matching', in case we come up with other kinds of tests by which we want to `guard'. But maybe those could then be integrated into _guard and selected via options or something. Bye Sven Index: Completion/Base/Utility/_arguments =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_arguments,v retrieving revision 1.3 diff -u -r1.3 _arguments --- Completion/Base/Utility/_arguments 2001/04/05 12:12:47 1.3 +++ Completion/Base/Utility/_arguments 2001/04/26 12:10:16 @@ -4,7 +4,7 @@ # descriptions given as arguments to this function. local long cmd="$words[1]" descr mesg subopts opt usecc autod -local oldcontext="$curcontext" hasopts rawret optarg singopt +local oldcontext="$curcontext" hasopts rawret optarg singopt alwopt long=$argv[(I)--] if (( long )); then @@ -174,21 +174,22 @@ subopts=() singopt=() -while [[ "$1" = -(O*|[CRWs]) ]]; do +while [[ "$1" = -(O*|[CRWsw]) ]]; do case "$1" in -C) usecc=yes; shift ;; -O) subopts=( "${(@P)2}" ); shift 2 ;; -O*) subopts=( "${(@P)1[3,-1]}" ); shift ;; -R) rawret=yes; shift;; - -W) optarg=yes; shift;; + -w) optarg=yes; shift;; -s) singopt=(-s); shift;; + -W) alwopt=yes; shift;; esac done zstyle -s ":completion:${curcontext}:options" auto-description autod if (( $# )) && comparguments -i "$autod" "$singopt[@]" "$@"; then - local action noargs aret expl local tried + local action noargs aret expl local tried ret=1 local next direct odirect equal single matcher matched ws tmp1 tmp2 tmp3 local opts subc tc prefix suffix descrs actions subcs anum local origpre="$PREFIX" origipre="$IPREFIX" nm="$compstate[nmatches]" @@ -280,7 +281,8 @@ eval ws\=\( "${action[3,-3]}" \) - _describe -t "$subc" "$descr" ws -M "$matcher" "$subopts[@]" + _describe -t "$subc" "$descr" ws -M "$matcher" "$subopts[@]" || + alwopt=yes tried=yes elif [[ "$action" = \(*\) ]]; then @@ -289,15 +291,17 @@ eval ws\=\( "${action[2,-2]}" \) - _all_labels "$subc" expl "$descr" compadd "$subopts[@]" -a - ws + _all_labels "$subc" expl "$descr" compadd "$subopts[@]" -a - ws || + alwopt=yes tried=yes elif [[ "$action" = \{*\} ]]; then # A string in braces is evaluated. while _next_label "$subc" expl "$descr"; do - eval "$action[2,-2]" + eval "$action[2,-2]" && ret=0 done + (( ret )) && alwopt=yes tried=yes elif [[ "$action" = \ * ]]; then @@ -305,8 +309,9 @@ eval "action=( $action )" while _next_label "$subc" expl "$descr"; do - "$action[@]" + "$action[@]" && ret=0 done + (( ret )) && alwopt=yes tried=yes else @@ -314,15 +319,17 @@ eval "action=( $action )" while _next_label "$subc" expl "$descr"; do - "$action[1]" "$subopts[@]" "$expl[@]" "${(@)action[2,-1]}" + "$action[1]" "$subopts[@]" "$expl[@]" "${(@)action[2,-1]}" && ret=0 done + (( ret )) && alwopt=yes tried=yes fi fi fi done - - if [[ -z "$matched$hasopts" && ( -z "$aret" || "$PREFIX" = "$origpre" ) ]] && + if [[ -z "$hasopts" && + ( -z "$matched" || -n "$alwopt" ) && + ( -z "$aret" || "$PREFIX" = "$origpre" ) ]] && _requested options && { ! zstyle -T ":completion:${curcontext}:options" prefix-needed || [[ "$origpre" = [-+]* || -z "$aret$mesg$tried" ]] } ; then @@ -378,9 +385,10 @@ PREFIX="$prevpre" IPREFIX="$previpre" fi - [[ -n "$tried" && "$PREFIX" != [-+]* ]] && break + [[ -n "$tried" && "${${alwopt:+$origpre}:-$PREFIX}" != [-+]* ]] && break done - if [[ -n "$opts" && -z "$aret$matched$mesg" && + if [[ -n "$opts" && -z "$aret" && + ( -z "$matched$mesg" || -n "$alwopt" ) && nm -eq compstate[nmatches] ]]; then PREFIX="$origpre" Index: Completion/Base/Utility/_guard =================================================================== RCS file: _guard diff -N _guard --- /dev/null Mon Dec 11 17:26:27 2000 +++ _guard Thu Apr 26 05:10:16 2001 @@ -0,0 +1,17 @@ +#autoload + +local mesg pat garbage + +mesg=() +zparseopts -K -D -a garbage M: J: V: 1 2 n F: X:=mesg + +[[ "$PREFIX$SUFFIX" != $~1 ]] && return 1 + +if [[ $# -gt 1 || $#mesg -eq 0 ]]; then + shift + _message "$*" +else + _message -r "$mesg[2]" +fi + +[[ -n "$PREFIX$SUFFIX" ]] Index: Completion/X/Utility/_x_arguments =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/X/Utility/_x_arguments,v retrieving revision 1.2 diff -u -r1.2 _x_arguments --- Completion/X/Utility/_x_arguments 2001/04/04 11:29:22 1.2 +++ Completion/X/Utility/_x_arguments 2001/04/26 12:10:16 @@ -17,7 +17,7 @@ fi opts=() -while [[ $1 = -(O*|[CRWs]) ]]; do +while [[ $1 = -(O*|[CRWsw]) ]]; do opts=($opts $1) [[ $1 = -R ]] && rawret=yes shift Index: Completion/X/Utility/_xt_arguments =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/X/Utility/_xt_arguments,v retrieving revision 1.2 diff -u -r1.2 _xt_arguments --- Completion/X/Utility/_xt_arguments 2001/04/04 11:29:22 1.2 +++ Completion/X/Utility/_xt_arguments 2001/04/26 12:10:16 @@ -53,7 +53,7 @@ fi opts=() -while [[ $1 = -(O*|[CRWs]) ]]; do +while [[ $1 = -(O*|[CRWsw]) ]]; do opts=($opts $1) [[ $1 = -R ]] && rawret=yes shift Index: Doc/Zsh/compsys.yo =================================================================== RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v retrieving revision 1.117 diff -u -r1.117 compsys.yo --- Doc/Zsh/compsys.yo 2001/04/04 11:29:22 1.117 +++ Doc/Zsh/compsys.yo 2001/04/26 12:10:21 @@ -2930,13 +2930,25 @@ one option name. This allows the use of the `tt(-s)' option to describe single-letter options together with such long option names. -The tt(-s) option may be combined with the option tt(-W) to say that more +The tt(-s) option may be combined with the option tt(-w) to say that more option characters are to be expected even after an option that takes an argument. For example, if a command takes the options `tt(a)' and `tt(b)', where `tt(a)' takes an argument in the next word, tt(_arguments) would normally not complete the other option directly after `tt(-a)', but it would -allow that if given the tt(-W) option. +allow that if given the tt(-w) option. +Similarly, the option tt(-W) may be given to force completion of options +even after options that get an argument in the same word. For example, +if a command takes the options `tt(a)' and `tt(b)', where `tt(a)' needs +an argument in the same word, directly after the option character, +tt(_arguments) would normally only execute the action for that argument +and not offer other options as possible completions. If given the +tt(-W) option, it will offer other options as possible completions after +executing the action for the argument. Note that, depending on the +action, this may mean that the other options can't really be completed, +but at least they will be listed. For more control, use an utility +function like tt(_guard) in the argument's action. + The forms of var(optspec) are: startitem() @@ -3498,6 +3510,38 @@ from the called function is stored in it. The return value of tt(_call_function) itself is zero if the function var(name) exists and was called and non-zero otherwise. +) +findex(_guard) +item(tt(_guard) [ var(options) ] var(pattern) [ var(descr) ])( +This function is intended to be used in an action of functions like +tt(_arguments). It returns immediately with a non-zero return value if +the string to be completed does not match the var(pattern). If the +pattern matches, the var(descr) is displayed and the function returns +zero if the word to complete is not empty and non-zero otherwise. + +The var(pattern) may be preceded by those options understood by +tt(compadd) that are passed down from tt(_description), namely tt(-M), +tt(-J), tt(-V), tt(-1), tt(-2), tt(-n), tt(-F) and tt(-X). All of these +options, except tt(-X), will be ignored. If the tt(-X) option appears, +the description following it will be used as the string to display if +the var(pattern) matches, unless the option var(descr) is given to +tt(_guard) itself, which will then take precedence. + +As an example, consider a command taking the options tt(-n) and +tt(-none), where tt(-n) has to be followed by a numeric value in the +same word. By using either of: + +example(_argument '-n-:numeric value:_guard "[0-9]#"' '-none') + +or + +example(_argument '-n-: :_guard "[0-9]#" "numeric value"' '-none') + +tt(_arguments) can be made to both display the message `tt(numeric +value)' and complete options after `tt(-n<TAB>)'. If the `tt(-n)' is +already followed by one or more digits (matching the pattern given to +tt(_guard)), only the message will be displayed and if the `tt(-n)' is +followed by another character, only options are completed. ) findex(_message) item(tt(_message) [ -r ] var(descr))( Index: Src/Zle/computil.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/computil.c,v retrieving revision 1.49 diff -u -r1.49 computil.c --- Src/Zle/computil.c 2001/04/25 09:05:12 1.49 +++ Src/Zle/computil.c 2001/04/26 12:10:27 @@ -1941,7 +1941,12 @@ case 's': for (; lstate; lstate = lstate->snext) if (lstate->d->single && lstate->singles && - lstate->actopts && lstate->opt) { + lstate->actopts +#if 0 + /* let's try without, for the -W option of _arguments */ + && lstate->opt +#endif + ) { setsparam(args[1], ztrdup((lstate->ddef && lstate->dopt) ? (lstate->dopt->type == CAO_DIRECT ? -- Sven Wischnowsky wischnow@informatik.hu-berlin.de ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: problem with _arguments exclusion lists 2001-04-23 8:59 ` Oliver Kiddle 2001-04-24 10:00 ` Sven Wischnowsky @ 2001-04-25 7:10 ` Sven Wischnowsky 1 sibling, 0 replies; 18+ messages in thread From: Sven Wischnowsky @ 2001-04-25 7:10 UTC (permalink / raw) To: zsh-workers I only just noticed that the mail I sent for this yesterday never made it to the list (or at least: back to me). Apologies if you get this twice. This adds the `-w' option to _arguments, a stronger form of -W, that makes it complete options even directly after options that get arguments in the same word. It also makes _arguments try to complete options in such places even without the -w option if the action for the argument returns a non-zero value. Then I suggest using the following as the pattern-matching function were discussed: local mesg pat garbage mesg=() zparseopts -K -D -a garbage M: J: V: 1 2 n F: X:=mesg [[ "$PREFIX$SUFFIX" != $~1 ]] && return 1 if [[ $# -gt 1 || $#mesg -eq 0 ]]; then shift _message "$*" else _message -r "$mesg[2]" fi [[ -n "$PREFIX$SUFFIX" ]] It ignores the compadd-options that might be passed down from _description and the like, but is able to extract the description from the -X option. The message to display can also be given as the second-to-last argument. The first argument (after any compadd-options) is the pattern to match. So, this can be used as in: _arguments -s '(-conf)-c+:numeric value:prop "[0-9]#"' '-conf' '-f' or: _arguments -s '(-conf)-c+: :prop "[0-9]#" numeric value' '-conf' '-f' and completes options (and displays the message) directly after `-c<TAB>', it only displays the message after `-c<digits><TAB>' and it only completes options after `-c<non-digits><TAB>'. This isn't committed yet, because I don't know how to call that utility function. Can someone please help me there? Oliver? Bye Sven Index: Completion/Base/Utility/_arguments =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_arguments,v retrieving revision 1.3 diff -u -r1.3 _arguments --- Completion/Base/Utility/_arguments 2001/04/05 12:12:47 1.3 +++ Completion/Base/Utility/_arguments 2001/04/25 07:03:13 @@ -4,7 +4,7 @@ # descriptions given as arguments to this function. local long cmd="$words[1]" descr mesg subopts opt usecc autod -local oldcontext="$curcontext" hasopts rawret optarg singopt +local oldcontext="$curcontext" hasopts rawret optarg singopt alwopt long=$argv[(I)--] if (( long )); then @@ -174,7 +174,7 @@ subopts=() singopt=() -while [[ "$1" = -(O*|[CRWs]) ]]; do +while [[ "$1" = -(O*|[CRWsw]) ]]; do case "$1" in -C) usecc=yes; shift ;; -O) subopts=( "${(@P)2}" ); shift 2 ;; @@ -182,13 +182,14 @@ -R) rawret=yes; shift;; -W) optarg=yes; shift;; -s) singopt=(-s); shift;; + -w) alwopt=yes; shift;; esac done zstyle -s ":completion:${curcontext}:options" auto-description autod if (( $# )) && comparguments -i "$autod" "$singopt[@]" "$@"; then - local action noargs aret expl local tried + local action noargs aret expl local tried ret=1 local next direct odirect equal single matcher matched ws tmp1 tmp2 tmp3 local opts subc tc prefix suffix descrs actions subcs anum local origpre="$PREFIX" origipre="$IPREFIX" nm="$compstate[nmatches]" @@ -280,7 +281,8 @@ eval ws\=\( "${action[3,-3]}" \) - _describe -t "$subc" "$descr" ws -M "$matcher" "$subopts[@]" + _describe -t "$subc" "$descr" ws -M "$matcher" "$subopts[@]" || + alwopt=yes tried=yes elif [[ "$action" = \(*\) ]]; then @@ -289,15 +291,17 @@ eval ws\=\( "${action[2,-2]}" \) - _all_labels "$subc" expl "$descr" compadd "$subopts[@]" -a - ws + _all_labels "$subc" expl "$descr" compadd "$subopts[@]" -a - ws || + alwopt=yes tried=yes elif [[ "$action" = \{*\} ]]; then # A string in braces is evaluated. while _next_label "$subc" expl "$descr"; do - eval "$action[2,-2]" + eval "$action[2,-2]" && ret=0 done + (( ret )) && alwopt=yes tried=yes elif [[ "$action" = \ * ]]; then @@ -305,8 +309,9 @@ eval "action=( $action )" while _next_label "$subc" expl "$descr"; do - "$action[@]" + "$action[@]" && ret=0 done + (( ret )) && alwopt=yes tried=yes else @@ -314,15 +319,17 @@ eval "action=( $action )" while _next_label "$subc" expl "$descr"; do - "$action[1]" "$subopts[@]" "$expl[@]" "${(@)action[2,-1]}" + "$action[1]" "$subopts[@]" "$expl[@]" "${(@)action[2,-1]}" && ret=0 done + (( ret )) && alwopt=yes tried=yes fi fi fi done - - if [[ -z "$matched$hasopts" && ( -z "$aret" || "$PREFIX" = "$origpre" ) ]] && + if [[ -z "$hasopts" && + ( -z "$matched" || -n "$alwopt" ) && + ( -z "$aret" || "$PREFIX" = "$origpre" ) ]] && _requested options && { ! zstyle -T ":completion:${curcontext}:options" prefix-needed || [[ "$origpre" = [-+]* || -z "$aret$mesg$tried" ]] } ; then @@ -378,9 +385,10 @@ PREFIX="$prevpre" IPREFIX="$previpre" fi - [[ -n "$tried" && "$PREFIX" != [-+]* ]] && break + [[ -n "$tried" && "${${alwopt:+$origpre}:-$PREFIX}" != [-+]* ]] && break done - if [[ -n "$opts" && -z "$aret$matched$mesg" && + if [[ -n "$opts" && -z "$aret" && + ( -z "$matched$mesg" || -n "$alwopt" ) && nm -eq compstate[nmatches] ]]; then PREFIX="$origpre" Index: Completion/X/Utility/_x_arguments =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/X/Utility/_x_arguments,v retrieving revision 1.2 diff -u -r1.2 _x_arguments --- Completion/X/Utility/_x_arguments 2001/04/04 11:29:22 1.2 +++ Completion/X/Utility/_x_arguments 2001/04/25 07:03:14 @@ -17,7 +17,7 @@ fi opts=() -while [[ $1 = -(O*|[CRWs]) ]]; do +while [[ $1 = -(O*|[CRWsw]) ]]; do opts=($opts $1) [[ $1 = -R ]] && rawret=yes shift Index: Completion/X/Utility/_xt_arguments =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/X/Utility/_xt_arguments,v retrieving revision 1.2 diff -u -r1.2 _xt_arguments --- Completion/X/Utility/_xt_arguments 2001/04/04 11:29:22 1.2 +++ Completion/X/Utility/_xt_arguments 2001/04/25 07:03:14 @@ -53,7 +53,7 @@ fi opts=() -while [[ $1 = -(O*|[CRWs]) ]]; do +while [[ $1 = -(O*|[CRWsw]) ]]; do opts=($opts $1) [[ $1 = -R ]] && rawret=yes shift Index: Doc/Zsh/compsys.yo =================================================================== RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v retrieving revision 1.117 diff -u -r1.117 compsys.yo --- Doc/Zsh/compsys.yo 2001/04/04 11:29:22 1.117 +++ Doc/Zsh/compsys.yo 2001/04/25 07:03:16 @@ -2937,6 +2937,18 @@ normally not complete the other option directly after `tt(-a)', but it would allow that if given the tt(-W) option. +Similarly, the option tt(-w) may be given to force completion of options +even after options that get an argument in the same word. For example, +if a command takes the options `tt(a)' and `tt(b)', where `tt(a)' needs +an argument in the same word, directly after the option character, +tt(_arguments) would normally only execute the action for that argument +and not offer other options as possible completions. If given the +tt(-w) option, it will offer other options as possible completions after +executing the action for the argument. Note that, depending on the +action, this may mean that the other options can't really be completed, +but at least they will be listed. For more control, use an utility +function like tt(_XXX) in the argument's action. + The forms of var(optspec) are: startitem() Index: Src/Zle/computil.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/computil.c,v retrieving revision 1.48 diff -u -r1.48 computil.c --- Src/Zle/computil.c 2001/04/17 09:52:32 1.48 +++ Src/Zle/computil.c 2001/04/25 07:03:17 @@ -1941,7 +1941,12 @@ case 's': for (; lstate; lstate = lstate->snext) if (lstate->d->single && lstate->singles && - lstate->actopts && lstate->opt) { + lstate->actopts +#if 0 + /* let's try without, for the -w option of _arguments */ + && lstate->opt +#endif + ) { setsparam(args[1], ztrdup((lstate->ddef && lstate->dopt) ? (lstate->dopt->type == CAO_DIRECT ? -- Sven Wischnowsky wischnow@informatik.hu-berlin.de ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: problem with _arguments exclusion lists @ 2001-04-26 13:55 Oliver Kiddle 2001-04-26 14:35 ` Sven Wischnowsky 0 siblings, 1 reply; 18+ messages in thread From: Oliver Kiddle @ 2001-04-26 13:55 UTC (permalink / raw) To: zsh-workers --- Sven Wischnowsky <wischnow@informatik.hu-berlin.de> wrote: > Oliver Kiddle wrote: > > > [[ -n "$PREFIX$SUFFIX" ]] > > In the case you described next: If the word to complete is empty I > want > it to both display the message and complete options. I noticed that > only when I had implemented (before, we were discussing only two > cases: > message *or* options). But if the word is empty, and the pattern matches, it does offer both message and options. I think this check should come before the _message and an empty $PREFIX$SUFFIX should prevent the failed return. Like this: [[ -n $PREFIX$SUFFIX && "$PREFIX$SUFFIX" != $~1 ]] && return 1 The completion for vncserver (patch below) could use this so that it offers display numbers before the initial `:' is typed. When, in the first message you say `the new behaviour of completing options if the action returns non-zero', I would have said that the behaviour was to be not claiming to complete the message when actions return non-zero so that completing other things, like options isn't blocked. > No, -w (now -W since I swapped them), makes it complete options > regardless of the return value of the action. What you're seeing > here > is the new default behaviour of trying to complete options if the > action returns non-zero. Oh. I thought it was going to not complete single letter options unless it had -W and -s and always complete long options. So how do I get _pine to work properly (use of _guard for _pine also in the patch): valid pine -cr4 produces an error message so pine -r<tab> offers other single letter options including -c pine -c<tab> should offer -conf, -character-set etc but not other single letter options like -r. It should also offer numbers. I thought the _arguments -W option was going to allow it to offer single letter options like -r for any command which allows options between an option and its argument where they are all in the same word. So -W wouldn't be used for pine and the -r option wouldn't be offered between -c and its number argument. > I was hoping for something short, but still alluding to `matching', > in > case we come up with other kinds of tests by which we want to > `guard'. > But maybe those could then be integrated into _guard and selected via > options or something. It can always be renamed if we think of a better name or change it's behaviour. Oliver Index: Completion/Base/Utility/.distfiles =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/.distfiles,v retrieving revision 1.1 diff -u -r1.1 .distfiles --- Completion/Base/Utility/.distfiles 2001/04/02 12:42:44 1.1 +++ Completion/Base/Utility/.distfiles 2001/04/26 13:52:06 @@ -2,7 +2,7 @@ .distfiles _alternative _call_program _nothing _sub_commands _arg_compile _combination _regex_arguments _values -_arguments _contexts _retrieve_cache +_arguments _contexts _retrieve_cache _guard _cache_invalid _describe _sep_parts _call_function _multi_parts _store_cache ' Index: Completion/Unix/Command/_pine =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/Unix/Command/_pine,v retrieving revision 1.1 diff -u -r1.1 _pine --- Completion/Unix/Command/_pine 2001/04/13 18:42:15 1.1 +++ Completion/Unix/Command/_pine 2001/04/26 13:52:06 @@ -31,11 +31,11 @@ "($opts $idx -url)-attach_and_delete[go to composer, attach file, delete when finished]:file:_files" \ "($opts $idx $send)-url[open the given URL]:url:->url" \ "($opts $send)-f+[specify mailbox to load]:mailbox: _mailboxes" \ - "($opts $send)-c+[specify context to apply to -f arg]:number" \ + "($opts $send)-c+[specify context to apply to -f arg]:number:_guard '[0-9]#'" \ "($opts $send)-sort[specify sort order of folder]:sort order:(${(j: :)sortorder})" \ "($opts $send)-i[go directly to index, bypassing main menu]" \ "($opts $send)-I+[specify initial keystrokes to be executed]:keystrokes" \ - "($opts $send)-n+[entry in index to begin on]:number" \ + "($opts $send)-n+[entry in index to begin on]:number:_guard '[0-9]#'" \ "($opts $send)-o[open first folder read-only]" \ "(-F -h)-r[restricted - can only send mail to oneself]" \ "(${opts#-F})-k[force use of function keys]" \ Index: Completion/X/Command/.distfiles =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/X/Command/.distfiles,v retrieving revision 1.1 diff -u -r1.1 .distfiles --- Completion/X/Command/.distfiles 2001/04/02 12:43:42 1.1 +++ Completion/X/Command/.distfiles 2001/04/26 13:52:06 @@ -1,5 +1,5 @@ DISTFILES_SRC=' .distfiles _gv _netscape _xauth _xfig _xrdb _xterm _xwit -_nedit _x_utils _xdvi _xmodmap _xset _xv +_nedit _vnc _x_utils _xdvi _xmodmap _xset _xv ' Index: Completion/X/Command/_vnc =================================================================== RCS file: _vnc diff -N _vnc --- /dev/null Mon Dec 11 17:26:27 2000 +++ _vnc Thu Apr 26 06:52:06 2001 @@ -0,0 +1,32 @@ +#compdef vncserver vncviewer + +local displays args +displays=( ~/.vnc/$HOST:?.pid(N:r:t:s/$HOST//) ) +displays=( \\${^displays} ) + +case $service in + vncserver) + # currently lacking Xvnc arguments + _arguments \ + - start \ + '-name:desktop name:_x_name' \ + '-geometry:geometry:(1600x1200 1280x1024 1152x864 1024x768 800x600 640x480)' \ + '-depth:pixel depth:(8 16 24 32)' \ + '-pixelformat:pixel format' \ + '1::display number:_guard ":[0-9]#"' \ + - kill \ + "-kill:display number:($displays)" \ + - help \ + '-help' + ;; + vncviewer) + # should allow list for -encodings + _xt_arguments -shared -viewonly -fullscreen -bgr233 -owncmap -truecolour \ + '-encodings:encodings:(copyrect hextile corre rre raw)' \ + '-depth:depth' \ + '-passwd:file:_files' \ + '(1)-listen:display number' \ + '(-listen)1::display:_x_display' + ;; +esac + ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: problem with _arguments exclusion lists 2001-04-26 13:55 Oliver Kiddle @ 2001-04-26 14:35 ` Sven Wischnowsky 2001-05-04 16:20 ` Oliver Kiddle 0 siblings, 1 reply; 18+ messages in thread From: Sven Wischnowsky @ 2001-04-26 14:35 UTC (permalink / raw) To: zsh-workers Oliver Kiddle wrote: > ... > > But if the word is empty, and the pattern matches, it does offer both > message and options. I think this check should come before the > _message and an empty $PREFIX$SUFFIX should prevent the failed return. > Like this: > [[ -n $PREFIX$SUFFIX && "$PREFIX$SUFFIX" != $~1 ]] && return 1 If we do that, no options will be completed after, e.g. `pine -c' (with your patch), because then the action returned zero. > The completion for vncserver (patch below) could use this so that it > offers display numbers before the initial `:' is typed. I admit that I never thought about using this in a normal-argument spec (non-option-argument). Isn't that already covered enough by the normal behaviour of _arguments? I.e., using some other action for that argument that displays the message and handles the colon (I don't know how this argument has to look like...). > When, in the first message you say `the new behaviour of completing > options if the action returns non-zero', I would have said that the > behaviour was to be not claiming to complete the message when actions > return non-zero so that completing other things, like options isn't > blocked. That part of the `behaviour' depends on whatever the action does, obviously. And I think that the current behaviour of _guard is at least a good default. As I said, we can give it an option to say what should be done (returned) if the word is the empty string. > > No, -w (now -W since I swapped them), makes it complete options > > regardless of the return value of the action. What you're seeing > > here > > is the new default behaviour of trying to complete options if the > > action returns non-zero. > > Oh. I thought it was going to not complete single letter options > unless it had -W and -s and always complete long options. So how do I > get _pine to work properly (use of _guard for _pine also in the > patch): > > valid > pine -cr4 produces an error message > > so pine -r<tab> offers other single letter options including -c pine > -c<tab> should offer -conf, -character-set etc but not other single > letter options like -r. It should also offer numbers. [See? That last one... that's what you get with the current behaviour of _guard and _arguments.] > I thought the > _arguments -W option was going to allow it to offer single letter > options like -r for any command which allows options between an option > and its argument where they are all in the same word. So -W wouldn't be > used for pine and the -r option wouldn't be offered between -c and its > number argument. Ah, right. That makes sense. Patch below. Bye Sven Index: Completion/Base/Utility/_arguments =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_arguments,v retrieving revision 1.4 diff -u -r1.4 _arguments --- Completion/Base/Utility/_arguments 2001/04/26 12:13:37 1.4 +++ Completion/Base/Utility/_arguments 2001/04/26 14:34:38 @@ -182,7 +182,7 @@ -R) rawret=yes; shift;; -w) optarg=yes; shift;; -s) singopt=(-s); shift;; - -W) alwopt=yes; shift;; + -W) alwopt=arg; shift;; esac done @@ -282,7 +282,7 @@ eval ws\=\( "${action[3,-3]}" \) _describe -t "$subc" "$descr" ws -M "$matcher" "$subopts[@]" || - alwopt=yes + alwopt=${alwopt:-yes} tried=yes elif [[ "$action" = \(*\) ]]; then @@ -292,7 +292,7 @@ eval ws\=\( "${action[2,-2]}" \) _all_labels "$subc" expl "$descr" compadd "$subopts[@]" -a - ws || - alwopt=yes + alwopt=${alwopt:-yes} tried=yes elif [[ "$action" = \{*\} ]]; then @@ -301,7 +301,7 @@ while _next_label "$subc" expl "$descr"; do eval "$action[2,-2]" && ret=0 done - (( ret )) && alwopt=yes + (( ret )) && alwopt=${alwopt:-yes} tried=yes elif [[ "$action" = \ * ]]; then @@ -311,7 +311,7 @@ while _next_label "$subc" expl "$descr"; do "$action[@]" && ret=0 done - (( ret )) && alwopt=yes + (( ret )) && alwopt=${alwopt:-yes} tried=yes else @@ -321,7 +321,7 @@ while _next_label "$subc" expl "$descr"; do "$action[1]" "$subopts[@]" "$expl[@]" "${(@)action[2,-1]}" && ret=0 done - (( ret )) && alwopt=yes + (( ret )) && alwopt=${alwopt:-yes} tried=yes fi fi @@ -340,7 +340,8 @@ PREFIX="$origpre" IPREFIX="$origipre" - if comparguments -s single; then + if [[ -z "$alwopt" || -z "$tried" || "$alwopt" = arg ]] && + comparguments -s single; then if [[ "$single" = direct ]]; then _all_labels options expl option \ Index: Doc/Zsh/compsys.yo =================================================================== RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v retrieving revision 1.119 diff -u -r1.119 compsys.yo --- Doc/Zsh/compsys.yo 2001/04/26 13:03:24 1.119 +++ Doc/Zsh/compsys.yo 2001/04/26 14:34:41 @@ -2938,17 +2938,18 @@ normally not complete the other option directly after `tt(-a)', but it would allow that if given the tt(-w) option. -Similarly, the option tt(-W) may be given to force completion of options -even after options that get an argument in the same word. For example, -if a command takes the options `tt(a)' and `tt(b)', where `tt(a)' needs -an argument in the same word, directly after the option character, -tt(_arguments) would normally only execute the action for that argument -and not offer other options as possible completions. If given the -tt(-W) option, it will offer other options as possible completions after -executing the action for the argument. Note that, depending on the -action, this may mean that the other options can't really be completed, -but at least they will be listed. For more control, use an utility -function like tt(_guard) in the argument's action. +Similarly, the option tt(-W) may be given together with tt(-s) to force +completion of single-letter options even after options that get an +argument in the same word. For example, if a command takes the options +`tt(a)' and `tt(b)', where `tt(a)' needs an argument in the same word, +directly after the option character, tt(_arguments) would normally only +execute the action for that argument and not offer other single-letter +options as possible completions. If given the tt(-W) option, it will +offer other options as possible completions after executing the action +for the argument. Note that, depending on the action, this may mean +that the other options can't really be completed, but at least they will +be listed. For more control, use an utility function like tt(_guard) in +the argument's action. The forms of var(optspec) are: -- Sven Wischnowsky wischnow@informatik.hu-berlin.de ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: problem with _arguments exclusion lists 2001-04-26 14:35 ` Sven Wischnowsky @ 2001-05-04 16:20 ` Oliver Kiddle 2001-05-07 11:10 ` Sven Wischnowsky 0 siblings, 1 reply; 18+ messages in thread From: Oliver Kiddle @ 2001-05-04 16:20 UTC (permalink / raw) To: zsh-workers Sven Wischnowsky wrote: > > > [[ -n $PREFIX$SUFFIX && "$PREFIX$SUFFIX" != $~1 ]] && return 1 > > If we do that, no options will be completed after, e.g. `pine -c' (with > your patch), because then the action returned zero. You're right. I got mixed up. I still don't like that last line in _guard though. I think that maybe when _guard returns 0, matching options should still be offered so a -c3nf option could be matched and options would be offered after pine -c without that last line in _guard. The important original point was really what happens when _guard returns 1 and that is now right. Apart from the minor point above, I am now happy that this all works so thanks Sven. Sorry for being slow about replying to this last e-mail > I admit that I never thought about using this in a normal-argument spec > (non-option-argument). Isn't that already covered enough by the normal > behaviour of _arguments? I.e., using some other action for that > argument that displays the message and handles the colon (I don't know > how this argument has to look like...). It can't really be handled by anything else unless there is a specific maximum to X display numbers allowing us to add all possibilities. _guard is actually particularly valuable in the non-option argument case because before the recent changes options would not complete. The problem really is that the _guard patterns have to match fully, not partially: _vnc can be fixed by using the pattern (|:[0-9]#) which I'll commit later if _guard stays as it is. Oliver _____________________________________________________________________ This message has been checked for all known viruses by the MessageLabs Virus Scanning Service. For further information visit http://www.messagelabs.com/stats.asp ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: problem with _arguments exclusion lists 2001-05-04 16:20 ` Oliver Kiddle @ 2001-05-07 11:10 ` Sven Wischnowsky 2001-05-08 11:45 ` Oliver Kiddle 0 siblings, 1 reply; 18+ messages in thread From: Sven Wischnowsky @ 2001-05-07 11:10 UTC (permalink / raw) To: zsh-workers Oliver Kiddle wrote: > Sven Wischnowsky wrote: > > > > > [[ -n $PREFIX$SUFFIX && "$PREFIX$SUFFIX" != $~1 ]] && return 1 > > > > If we do that, no options will be completed after, e.g. `pine -c' (with > > your patch), because then the action returned zero. > > You're right. I got mixed up. I still don't like that last line in > _guard though. I think that maybe when _guard returns 0, matching > options should still be offered so a -c3nf option could be matched and > options would be offered after pine -c without that last line in _guard. > The important original point was really what happens when _guard returns > 1 and that is now right. > > ... > > It can't really be handled by anything else unless there is a specific > maximum to X display numbers allowing us to add all possibilities. > _guard is actually particularly valuable in the non-option argument case > because before the recent changes options would not complete. The > problem really is that the _guard patterns have to match fully, not > partially: _vnc can be fixed by using the pattern (|:[0-9]#) which I'll > commit later if _guard stays as it is. Well, _guard was just an attempt at helping in what I consider the usual completion style in most cases (i.e. what most people would expect or like to see in most cases). As I said, we could always add an option to _guard to specify other behaviour (for the return value or pattern matching or whatnot). Feel free to add one if you like. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: problem with _arguments exclusion lists 2001-05-07 11:10 ` Sven Wischnowsky @ 2001-05-08 11:45 ` Oliver Kiddle 0 siblings, 0 replies; 18+ messages in thread From: Oliver Kiddle @ 2001-05-08 11:45 UTC (permalink / raw) To: zsh-workers Sven Wischnowsky wrote: \x1a > > partially: _vnc can be fixed by using the pattern (|:[0-9]#) which I'll > > commit later if _guard stays as it is. I'll commit this now. > > Well, _guard was just an attempt at helping in what I consider the usual > completion style in most cases (i.e. what most people would expect or > like to see in most cases). As I said, we could always add an option to > _guard to specify other behaviour (for the return value or pattern > matching or whatnot). Feel free to add one if you like. Well it is really the _arguments handling of a 0 return code and not _guard which I believe could be bettered. That is, it should complete possible options (like the -c3nf example) as well as displaying `number'. I'm happy to require _guard patterns to need to match their thing partially, hence the commit on the _vnc change. I agree though that _guard's style of pattern matching can always be extended with an option later if the need arises. Oliver Index: Completion/X/Command/_vnc =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/X/Command/_vnc,v retrieving revision 1.1 diff -u -r1.1 _vnc --- Completion/X/Command/_vnc 2001/04/26 14:00:45 1.1 +++ Completion/X/Command/_vnc 2001/05/08 11:43:40 @@ -13,7 +13,7 @@ '-geometry:geometry:(1600x1200 1280x1024 1152x864 1024x768 800x600 640x480)' \ '-depth:pixel depth:(8 16 24 32)' \ '-pixelformat:pixel format' \ - '1::display number:_guard ":[0-9]#"' \ + '1::display number:_guard "(|:[0-9]#)"' \ - kill \ "-kill:display number:($displays)" \ - help \ ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2001-05-08 11:45 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-04-12 14:32 problem with _arguments exclusion lists Oliver Kiddle 2001-04-17 9:50 ` Sven Wischnowsky 2001-04-17 10:44 ` Oliver Kiddle 2001-04-17 11:28 ` Sven Wischnowsky 2001-04-17 13:55 ` Oliver Kiddle 2001-04-17 14:10 ` Sven Wischnowsky 2001-04-19 14:01 ` Oliver Kiddle 2001-04-20 8:31 ` Sven Wischnowsky 2001-04-23 8:59 ` Oliver Kiddle 2001-04-24 10:00 ` Sven Wischnowsky 2001-04-26 11:00 ` Oliver Kiddle 2001-04-26 12:10 ` Sven Wischnowsky 2001-04-25 7:10 ` Sven Wischnowsky 2001-04-26 13:55 Oliver Kiddle 2001-04-26 14:35 ` Sven Wischnowsky 2001-05-04 16:20 ` Oliver Kiddle 2001-05-07 11:10 ` Sven Wischnowsky 2001-05-08 11:45 ` Oliver Kiddle
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).