Re: Two missing completion functions that bug me

Re: Two missing completion functions that bug me

[Sven Wischnowsky]

Oliver Kiddle wrote:

> --- Bart Schaefer <schaefer@candle.brasslantern.com> wrote:
> 
> > Yes, but when you're allowed to have other options intervene between
> > an
> > option and its argument (as in `tar -fxv file' for example) there has
> > to
> > be some way to prevent completion from inserting the space after
> > `-f'.
> 
> I accept this but would argue that there are more commands which don't
> allow other options to intervene. Things like tar can be achieved with
> with states. Maybe _arguments needs some way to describe whether or not
> options can intervene between an option and its argument.

Yes, I was beginning to think the same.  Would it be enough to make my 
other patch optional (i.e. adding a option to _arguments to select
either that behaviour or to de-select it)?  Which should be the
default?

> Things get
> messy if more than one of the options take an argument.

If I understand you correctly... I said in one of my previous messages 
that _arguments can do that.  Do we have to disallow it?  I'd prefer
it if we could keep it, mostly because I don't see a reason to make it 
optional -- either it's the intended reason or the specs given to
_arguments or the command line are messed up (only in the last case
there may be a reason to make _arguments smart enough to detect it and 
notify the user).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Two missing completion functions that bug me

[Oliver Kiddle]

Sven Wischnowsky wrote: 

> > with states. Maybe _arguments needs some way to describe whether or
> not
> > options can intervene between an option and its argument.
> 
> Yes, I was beginning to think the same.  Would it be enough to make
> my 
> other patch optional (i.e. adding a option to _arguments to select
> either that behaviour or to de-select it)?  Which should be the
> default?

That sounds reasonable. I think the current behaviour (without your
other patch) should be the default because I think it is more common
but I'm not particularly bothered.

> If I understand you correctly... I said in one of my previous
> messages 
> that _arguments can do that.  Do we have to disallow it?  I'd prefer

Having just worked out how _arguments currently handles the situation,
I'd happy for it to be kept it as it is. It works in the most sensible
way which is possibly useful for some commands and not too harmful for
others.

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

PATCH: Re: Two missing completion functions that bug me

[Sven Wischnowsky]

Oliver Kiddle wrote:

> > Yes, I was beginning to think the same.  Would it be enough to make
> > my 
> > other patch optional (i.e. adding a option to _arguments to select
> > either that behaviour or to de-select it)?  Which should be the
> > default?
> 
> That sounds reasonable. I think the current behaviour (without your
> other patch) should be the default because I think it is more common
> but I'm not particularly bothered.

Just what I thought... I've used `-W', couldn't think of a better character.


Bye
  Sven

Index: Completion/Base/Utility/_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_arguments,v
retrieving revision 1.1
diff -u -r1.1 _arguments
--- Completion/Base/Utility/_arguments	2001/04/02 11:09:34	1.1
+++ Completion/Base/Utility/_arguments	2001/04/04 11:21:05
@@ -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
+local oldcontext="$curcontext" hasopts rawret optarg singopt
 
 long=$argv[(I)--]
 if (( long )); then
@@ -173,18 +173,21 @@
 fi
 
 subopts=()
-while [[ "$1" = -(O*|[CR]) ]]; do
+singopt=()
+while [[ "$1" = -(O*|[CRWs]) ]]; 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;;
+  -s)  singopt=(-s); shift;;
   esac
 done
 
 zstyle -s ":completion:${curcontext}:options" auto-description autod
 
-if (( $# )) && comparguments -i "$autod" "$@"; then
+if (( $# )) && comparguments -i "$autod" "$singopt[@]" "$@"; then
   local action noargs aret expl local tried
   local next direct odirect equal single matcher matched ws tmp1 tmp2 tmp3
   local opts subc tc prefix suffix descrs actions subcs anum
@@ -335,14 +338,19 @@
           if [[ "$single" = direct ]]; then
             _all_labels options expl option \
 	        compadd -QS '' - "${PREFIX}${SUFFIX}"
-          elif [[ "$single" = next ]]; then
+          elif [[ -z "$optarg" && "$single" = next ]]; then
             _all_labels options expl option \
 	        compadd -Q - "${PREFIX}${SUFFIX}"
           elif [[ "$single" = equal ]]; then
             _all_labels options expl option \
 	        compadd -QqS= - "${PREFIX}${SUFFIX}"
           else
+
 	    tmp1=( "$next[@]" "$direct[@]" "$odirect[@]" "$equal[@]" )
+
+            [[ "$single" = next ]] &&
+                tmp1=( "${(@)tmp1:#[-+]${PREFIX[-1]}((#e)|:*)}" )
+
 	    [[ "$PREFIX" != --* ]] && tmp1=( "${(@)tmp1:#--*}" )
 	    tmp3=( "${(M@)tmp1:#[-+]?[^:]*}" )
 	    tmp1=( "${(M@)tmp1:#[-+]?(|:*)}" )
@@ -351,6 +359,11 @@
             _describe -o option \
                       tmp1 tmp2 -Q -S '' -- \
 		      tmp3 -Q
+
+            [[ -n "$optarg" && "$single" = next && nm -eq $compstate[nmatches] ]] &&
+                _all_labels options expl option \
+	            compadd -Q - "${PREFIX}${SUFFIX}"
+
           fi
           single=yes
         else
Index: Completion/X/Utility/_x_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/X/Utility/_x_arguments,v
retrieving revision 1.1
diff -u -r1.1 _x_arguments
--- Completion/X/Utility/_x_arguments	2001/04/02 12:13:15	1.1
+++ Completion/X/Utility/_x_arguments	2001/04/04 11:21:05
@@ -17,7 +17,7 @@
 fi
 
 opts=()
-while [[ $1 = -(O*|[CR]) ]]; do
+while [[ $1 = -(O*|[CRWs]) ]]; 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.1
diff -u -r1.1 _xt_arguments
--- Completion/X/Utility/_xt_arguments	2001/04/02 12:13:30	1.1
+++ Completion/X/Utility/_xt_arguments	2001/04/04 11:21:05
@@ -53,7 +53,7 @@
 fi
 
 opts=()
-while [[ $1 = -(O*|[CR]) ]]; do
+while [[ $1 = -(O*|[CRWs]) ]]; 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.116
diff -u -r1.116 compsys.yo
--- Doc/Zsh/compsys.yo	2001/04/02 13:04:05	1.116
+++ Doc/Zsh/compsys.yo	2001/04/04 11:21:07
@@ -2930,6 +2930,13 @@
 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
+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.
+
 The forms of var(optspec) are:
 
 startitem()
@@ -3202,6 +3209,13 @@
   - '(uncompress)' \ 
     {-d,--decompress}'[decompress]')
 
+Note that using multiple sets will be slower than using only one set
+because the completion code has to parse the command line once for
+every set. So more than one set should only be used if the command
+syntax is too complicated. Note also that an option specification with
+rest-arguments (as in `tt(-foo:*:...)') often allows the use of
+multiple sets to be avoided.
+
 To simplify the specifications for commands with standard option
 parsing, the options tt(-S) and tt(-A) may be given.  With tt(-S), no
 option will be completed after a `tt(-)tt(-)' on the line and this
@@ -3212,13 +3226,6 @@
 completing options after the first normal argument, but ignoring all
 strings starting with a hyphen even if they are not described by one
 of the var(optspec)s, one would use: `tt(-A "-*")'.
-
-Note that using multiple sets will be slower than using only one set
-because the completion code has to parse the command line once for
-every set. So more than one set should only be used if the command
-syntax is too complicated. Note also that an option specification with
-rest-arguments (as in `tt(-foo:*:...)') often allows the use of
-multiple sets to be avoided.
 
 Another option supported is `tt(-O) var(name)'. The var(name) will be
 taken as the name of an array and its elements will be given to

-- 
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Two missing completion functions that bug me

[Bart Schaefer]

On Mar 30,  5:35pm, Oliver Kiddle wrote:
} Subject: Re: Two missing completion functions that bug me
}
} % r -lD
} zsh: bad option: -D
} 
} It doesn't though. This is why I was confused - why should it accept -l
} but not -D. Is this something to do with ksh behaviour being used.

I suspect it's a historical artifact of `r' not being kept up to date with
all the options of `fc' rather than anything intentional.

According to builtin.c, `r' accepts only -n -l and -r (at the moment).  Hm.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Two missing completion functions that bug me

[Oliver Kiddle]

--- Bart Schaefer <schaefer@candle.brasslantern.com> wrote:

> Yes, but when you're allowed to have other options intervene between
> an
> option and its argument (as in `tar -fxv file' for example) there has
> to
> be some way to prevent completion from inserting the space after
> `-f'.

I accept this but would argue that there are more commands which don't
allow other options to intervene. Things like tar can be achieved with
with states. Maybe _arguments needs some way to describe whether or not
options can intervene between an option and its argument. Things get
messy if more than one of the options take an argument.

> Not entirely true: `vared -ca scalar' changes the type of an existing
I had a comment here, but I've just seen your next message where you
spotted it for yourself.

> Anything that `fc' does, with the exception of `-e'.  The -e option

% r -lD
zsh: bad option: -D

It doesn't though. This is why I was confused - why should it accept -l
but not -D. Is this something to do with ksh behaviour being used.
 
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

Re: Two missing completion functions that bug me

[Bart Schaefer]

On Mar 30, 10:21am, Sven Wischnowsky wrote:
}
} > I was thinking it was needed to get other options to be completed in the
} > same word, because of:
} > 
} > % vared -a<TAB>
} > % vared -a 
} >            ^cursor silently moves here
} > 
} > [...] Is there a way *other than* adding a ->state
} > machine to get other options to complete in the same word but arguments
} > in the next for an option like -a?
} 
} You could try the patch below, which does that (automatically) for
} me.  I'll commit it if we don't find any nasty side effect (or should
} I apply it and take it back if we find problems?  feel free to commit
} it if you like it...)

I haven't tried it yet, but what do you do if you *don't* want to allow
other single-letter options to be completed in the same word after one
that takes an argument (but do complete them in the same word *before*
the one that takes the argument)?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Two missing completion functions that bug me

[Bart Schaefer]

On Mar 30,  3:38pm, I wrote:
}
} Not entirely true: `vared -ca scalar' changes the type of an existing
} scalar to an array, as if you'd done `scalar=($scalar)'.  Same for -cA.

Which, I suppose, is an argument (ahem) for not attempting to guess the
type of parameter to be completed after -a or -A.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Two missing completion functions that bug me

[Bart Schaefer]

On Mar 30, 10:16am, Oliver Kiddle wrote:
} Subject: Re: Two missing completion functions that bug me
}
} --- Bart Schaefer <schaefer@candle.brasslantern.com> wrote:
} 
} > You're right; upon another attempt, none of -c, -e, nor -h need the
} > `+'.
} 
} The plus says that the argument to the option can appear in the same or
} subsequent word.

Yes, but when you're allowed to have other options intervene between an
option and its argument (as in `tar -fxv file' for example) there has to
be some way to prevent completion from inserting the space after `-f'.
In _rpm this is done by using both `+' and ->state so that options keep
completing in the same word and only when there are none possible (or
the next word is being completed) does the state machine get used to
supply the argument.

} The solution would be to use a state for the last (parameter) argument

However, I didn't think this much effort was worthwhile for vared, as
the number of options is small and they're not often used in combination
except in script/function context.

} and make it check $opt_args and select either _vars or _parameters
} depending on this. I'm not sure whether it is worth it to do this
} because -A and -a are only of any use if combined with -c so when
} creating a new array which won't exist to be completed anyway.

Not entirely true: `vared -ca scalar' changes the type of an existing
scalar to an array, as if you'd done `scalar=($scalar)'.  Same for -cA.

} I got confused as to why the r variant of fc allows -l.

So you can do `r -l FIRST [ LAST ]' for a listing.  It's just for those
too lazy to type a two-letter command name.  If you don't use the -l,
the commands from FIRST to LAST are actually *executed*.

} What should it take?

Anything that `fc' does, with the exception of `-e'.  The -e option is
ignored by fc and friends when -l is given so that you can have an
alias for `fc -e jove' or whatever (which is all `r' really is) and
still use the alias to get listings.

} Are getln and pushln of any use interactively? I got confused trying to
} alter _read and _print for them.

I've never had occasion to use them interactively, but I could conjure
a hypothetical scenario if pressed.

} pwd and echo would be fairly doable if we ignore the possibility of
} someone disabling them or using /bin/pwd.

We really need a way to do `whence' to discover whether $service is a
builtin or an external, without having to fork a process and parse its
output.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Two missing completion functions that bug me

[Oliver Kiddle]

--- Bart Schaefer <schaefer@candle.brasslantern.com> wrote:

> You're right; upon another attempt, none of -c, -e, nor -h need the
> `+'.

The plus says that the argument to the option can appear in the same or
subsequent word. I used it for only -p and -r. The -s passed to
_arguments allowed options to be in one word.

> but in fact that's because -a takes an argument, not (only) because

Actually, the way I had written this was to not specify that -a or -A
took an argument because they don't really. The manual shows:
  vared [-Aache] [-p prompt] [-r rprompt] name
I interpret this as meaning that -A and -a do not take an argument.
What they do is modify the type of the final argument (name).

For -a/-A, my function had just:
  '(-a)-A[create an associative array]' \
  '(-A)-a[create an array]' \
and I finished it with:
  '1:parameter:_vars'  # Note also, I used a 1 which you didn't
                       # - can only vared one parameter

so with -A or -a, mine wasn't going to limit completion to arrays. It
didn't really occur to be to use _parameters -g for them.

The solution would be to use a state for the last (parameter) argument
and make it check $opt_args and select either _vars or _parameters
depending on this. I'm not sure whether it is worth it to do this
because -A and -a are only of any use if combined with -c so when
creating a new array which won't exist to be completed anyway.

> } Would it be worth it to try to have completions for all builtins
> ready
> } for 4.0?
> Possibly.

I looked at a few yesterday and didn't get very far because it doesn't
make sense for many. I've got a few queries and thoughts:

I got confused as to why the r variant of fc allows -l. I thought it
would just use _command_names (and history numbers which we don't have
a function for). I only use zle based and csh style history so don't
know much about the ksh stuff. What should it take?

Are getln and pushln of any use interactively? I got confused trying to
alter _read and _print for them.

_ttyctl was a 5 second job so is done. (commit after Sven's great move)

pwd and echo would be fairly doable if we ignore the possibility of
someone disabling them or using /bin/pwd. Do any non-builtin pwd's take
any arguments? Any ideas on the types of echo? We really need the
generalised _is_gnu for this.

: by definition should use default completion so I'll leave it.

Is it worth doing one for test / [. It is tempting to define one to:
    _message 'use conditional expressions (with [[ ... ]]) instead'

> I get the same list as you, by comparing ${(k)_comps} to
> ${(k)builtins}.
Exactly what I did. I've got a static zsh without many modules here
though and there will be a few builtins which use something standard
like _parameters.

>   compadd        compdescribe   compgroups     compset        comptry
>   comparguments  compfiles      compquote      comptags      
> compvalues

True. There is your your point about interactive function writing
though. I also sometimes use zsh completion as a quicker alternatve to
man pages. Would anyone find any of these useful? I'm quite tempted to
write one for compadd.
 
> Similarly zregexparse, which although it could be used interactively,

Yes, I've never used that. I'm not even sure how many people other than
Akira and Sven have even looked at _regex_arguments. I only fairly
recently had a serious look at it and there were still quite a few
typos in the documentation (which I fixed) which just goes to show how
few people have looked at it.

> These don't need completions because they're keywords:
>   break     continue

so is nocorrect which does have a completion. Arguably, the completion
system should handle it elsewhere like it does with, for example while.

> Which leaves:
> 
>   :            echo         pushln       suspend      umask
>   [            exit         pwd          test         zformat
>   bye          getln        r            ttyctl       zparseopts
>   dirs         logout       return       ulimit       zprof

bye, exit and return could maybe share a functon which just calls
message with something like 'return code'.

ulimit could/should have a completion written. I've always used limit
being a tcsh convert but I'll look into this.

umask is fairly easy (but not very useful) so I'll do it. This reminds
me: ages ago I thought of doing an intelligent completion for chmod so
for example, chmod g+x would only complete files lacking group execute
permission.

> } Any ideas what should be done for commands with just one option
> } (like suspend) - completing -f might not be what people expect.
> 
> Behave as if prefix-needed is true.  Complete nothing unless the `-'
> is
> already there.

I was also wondering if it should maybe list the single -f option with
a description rather than completing it so you can see what it does.

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

Re: Two missing completion functions that bug me

[Sven Wischnowsky]

I wrote:

> ...
> 
> You could try the patch below ...

Ahem.

Bye
 Sven

Index: Completion/Base/_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/_arguments,v
retrieving revision 1.34
diff -u -r1.34 _arguments
--- Completion/Base/_arguments	2001/03/28 09:50:38	1.34
+++ Completion/Base/_arguments	2001/03/30 08:22:57
@@ -335,14 +335,16 @@
           if [[ "$single" = direct ]]; then
             _all_labels options expl option \
 	        compadd -QS '' - "${PREFIX}${SUFFIX}"
-          elif [[ "$single" = next ]]; then
-            _all_labels options expl option \
-	        compadd -Q - "${PREFIX}${SUFFIX}"
           elif [[ "$single" = equal ]]; then
             _all_labels options expl option \
 	        compadd -QqS= - "${PREFIX}${SUFFIX}"
           else
+
 	    tmp1=( "$next[@]" "$direct[@]" "$odirect[@]" "$equal[@]" )
+
+            [[ "$single" = next ]] &&
+                tmp1=( "${(@)tmp1:#[-+]${PREFIX[-1]}((#e)|:*)}" )
+
 	    [[ "$PREFIX" != --* ]] && tmp1=( "${(@)tmp1:#--*}" )
 	    tmp3=( "${(M@)tmp1:#[-+]?[^:]*}" )
 	    tmp1=( "${(M@)tmp1:#[-+]?(|:*)}" )
@@ -351,6 +353,11 @@
             _describe -o option \
                       tmp1 tmp2 -Q -S '' -- \
 		      tmp3 -Q
+
+            [[ "$single" = next && nm -eq $compstate[nmatches] ]] &&
+                _all_labels options expl option \
+	            compadd -Q - "${PREFIX}${SUFFIX}"
+
           fi
           single=yes
         else

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Two missing completion functions that bug me

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Mar 29, 11:09am, Oliver Kiddle wrote:
> }
> } >     '-c+[create parameter or change type]' \
> } 
> } I'm not sure you need the + after -c, or at least that is the only
> } difference to my function (other than wording for the help info).
> 
> You're right; upon another attempt, none of -c, -e, nor -h need the `+'.
> I was thinking it was needed to get other options to be completed in the
> same word, because of:
> 
> % vared -a<TAB>
> % vared -a 
>          ^cursor silently moves here
> 
> but in fact that's because -a takes an argument, not (only) because it
> does not have the `+'.  (Is there a way *other than* adding a ->state
> machine to get other options to complete in the same word but arguments
> in the next for an option like -a?  I was thinking not, and in fact I
> was thinking that I was one who asserted that ->state was a sufficient
> solution for this, a position I'm not inclined to change.)

You could try the patch below, which does that (automatically) for
me.  I'll commit it if we don't find any nasty side effect (or should
I apply it and take it back if we find problems?  feel free to commit
it if you like it...)

> ... [ comp* funcs ]
> 
> I suppose one could provide completions for them anyway, in case one is
> editing a new completion function on the fly, but it seems a lot of work
> for not a lot of benefit.

Yes, I thought the same.

> These don't need completions because they're keywords:
> 
>   break     continue
> 
> Which leaves:
> 
>   :            echo         pushln       suspend      umask
>   [            exit         pwd          test         zformat
>   bye          getln        r            ttyctl       zparseopts
>   dirs         logout       return       ulimit       zprof

zparseopts and zformat aren't of much use interactively either.

And completion for bye, exit and return seems weird, too.  Although
that would probably just be `_message "${${words[1]#bye}:-exit} value"'.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Two missing completion functions that bug me

[Bart Schaefer]

On Mar 29, 11:09am, Oliver Kiddle wrote:
}
} >     '-c+[create parameter or change type]' \
} 
} I'm not sure you need the + after -c, or at least that is the only
} difference to my function (other than wording for the help info).

You're right; upon another attempt, none of -c, -e, nor -h need the `+'.
I was thinking it was needed to get other options to be completed in the
same word, because of:

% vared -a<TAB>
% vared -a 
         ^cursor silently moves here

but in fact that's because -a takes an argument, not (only) because it
does not have the `+'.  (Is there a way *other than* adding a ->state
machine to get other options to complete in the same word but arguments
in the next for an option like -a?  I was thinking not, and in fact I
was thinking that I was one who asserted that ->state was a sufficient
solution for this, a position I'm not inclined to change.)

} Would it be worth it to try to have completions for all builtins ready
} for 4.0?

Possibly.

} I've put a (quickly generated so not ideal) list of all those
} which don't have a completion

I get the same list as you, by comparing ${(k)_comps} to ${(k)builtins}.
Arguably these don't need completions because they can't be used in an
interactive way:

  compadd        compdescribe   compgroups     compset        comptry
  comparguments  compfiles      compquote      comptags       compvalues

Similarly zregexparse, which although it could be used interactively,
doesn't make much sense outside _regex_arguments and is not really even
documented.

I suppose one could provide completions for them anyway, in case one is
editing a new completion function on the fly, but it seems a lot of work
for not a lot of benefit.

These don't need completions because they're keywords:

  break     continue

Which leaves:

  :            echo         pushln       suspend      umask
  [            exit         pwd          test         zformat
  bye          getln        r            ttyctl       zparseopts
  dirs         logout       return       ulimit       zprof

} Any ideas what should be done for commands with just one option
} (like suspend) - completing -f might not be what people expect.

Behave as if prefix-needed is true.  Complete nothing unless the `-' is
already there.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Two missing completion functions that bug me

[Oliver Kiddle]

--- Bart Schaefer <schaefer@candle.brasslantern.com> wrote: 

> ---- 8< ---- _vared ---- 8< ---

Damn, I was holding exactly that for afer Sven's big move and rename.

>     '-c+[create parameter or change type]' \

I'm not sure you need the + after -c, or at least that is the only
difference to my function (other than wording for the help info).

Would it be worth it to try to have completions for all builtins ready
for 4.0? I've put a (quickly generated so not ideal) list of all those
which don't have a completion below so feel free to mention requests or
views. Any ideas what should be done for commands with just one option
(like suspend) - completing -f might not be what people expect.

Oliver

ulimit
[
compfiles
pushln
exit
getln
pwd
zparseopts
logout
comptags
compdescribe
r
zregexparse
return
compadd
ttyctl
test
comparguments
comptry
zprof
compset
compvalues
compgroups
echo
dirs
:
bye
compquote
zformat
suspend
break
continue
umask

____________________________________________________________
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

Two missing completion functions that bug me

[Bart Schaefer]

I won't commit these yet (hence they're not presented in diff form); either
Sven can add them at the Great Renaming, or I'll add them after it happens.

The only reason for using _arguments in fned is to get "no more arguments"
behavior after the first name is completed; otherwise it could simply
call _functions directly.

---- 8< ---- _zed ---- 8< ---
#compdef zed fned
case $service in
(fned) _arguments ':shell function:_functions';;
(zed) _arguments '(-):file:_files' \
	'(:)-f[edit function]:shell function:_functions';;
esac
---- 8< ---- _zed ---- 8< ---

When adding this next one, remember to remove vared from _vars.

---- 8< ---- _vared ---- 8< ---
#compdef vared
_arguments -s -A '-*' ':parameter spec:_vars' \
    '(-A)-a[edit array parameter]:parameter name:_parameters -g array\*' \
    '(-a)-A[edit associative array]:parameter name:_parameters -g assoc\*' \
    '-c+[create parameter or change type]' \
    '-h+[enable history]' \
    '-e+[exit on EOF (^D)]' \
    '-p[specify left prompt]:prompt string:' \
    '-r[specify right prompt]:prompt string:'
---- 8< ---- _vared ---- 8< ---

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net