Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [SUBMIT] _ant completion function
- X-seq: zsh-users 5271
- From: Oliver Kiddle <okiddle@xxxxxxxxxxx>
- To: Felix Rosencrantz <f_rosencrantz@xxxxxxxxx>
- Subject: Re: [SUBMIT] _ant completion function
- Date: Tue, 20 Aug 2002 11:32:24 +0100
- Cc: Bill Burton <billb@xxxxxxxxxxxx>, Zsh users <zsh-users@xxxxxxxxxx>
- In-reply-to: <20020820010627.68232.qmail@xxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <E17gnoZ-0004m9-00@xxxxxxxxxxxxxxxxxx> <20020820010627.68232.qmail@xxxxxxxxxxxxxxxxxxxxxxx>
- Sender: Oliver Kiddle <kiddleo@xxxxxxxxxx>
On Mon, Aug 19, 2002 at 06:06:27PM -0700, Felix Rosencrantz wrote:
>
> Target elements have a "description" attribute, like they have a "name"
> attribute.
Okay thanks.
> > On the 4.1 branch, there is a _java_class function which is meant to do
> > this but I can't entirely make sense of what it is doing and how to get
> > it to use $ANT_HOME/lib/*.jar as you suggest. It ought to use
> > _multi_parts too.
>
> You don't explain what is confusing you. Though there are several things
Well, a number of things, some of which you've now explained.
In the latter half, after determining that $i is a directory, why does it
then ignore $i when putting together a list based on .class files? Seems
strange to me.
Can a classpath contain things like '*.jar' or for _ant should it be
expanding the glob.
> The other thing is that _java_class looks at opt_args for -classpath or -cp.
> This is ugly, really should be a better way to pass these values without
> having to go to a state.
There is a better way. Have a look in _figlet for an example. Basically
you can use an _arguments spec which looks something like this:
'*:class:_java_class -cp ${(v)~opt_args[(i)(-cp|-classpath)]\:-$CLASSPATH}'
so no states are needed.
It'd be cleaner if _java_class just had an argument to specify the
classpath like this.
> Could we add _java_class to 4.0? Is there something about it that would
> not allow us to add it?
I'd be in favour of adding it and can't see any particular reason not to.
> Also, adding caching for the build.xml targets/descriptions, and
> for _java_class jar files.
For cacheing the contents of jar files, it might be wise to use the same
cache used by _zip and allow jar completion to also use it.
Oliver
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author