Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: more selection
- X-seq: zsh-workers 17203
- From: Peter Stephenson <pws@xxxxxxx>
- To: zsh-workers@xxxxxxxxxx (Zsh hackers list)
- Subject: Re: PATCH: more selection
- Date: Tue, 21 May 2002 14:11:54 +0100
- In-reply-to: "Oliver Kiddle"'s message of "Tue, 21 May 2002 13:48:32 BST." <20020521124832.GA10428@xxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
Oliver Kiddle wrote:
> On Tue, May 21, 2002 at 12:21:27PM +0100, Peter Stephenson wrote:
>
> > only with zle -F, so that part could be done without the module if we
> > implemented the bash version of `read -t <timeout>'. It's annoying I
> > picked that letter for polling.)
>
> If the timeout is considered to be an optional argument, is there
> really any conflict there? The timeout defaulting to zero would
> give exactly the same as current behaviour so it could be compatible
> with both older zsh and bash/ksh93. right?
Yes, I was wondering about that. The major objection at the moment is
that zsh's internal handling for options with arguments is awful ---
look at the hacks for dealing with read -k and read -u, similarly
typeset -i/-Z/-R/-L. (I tried to combine read -k and -u and it took an
effort to work out what was happening.) I've been hoping for ages
someone would fix this and save me having to do anything.
The neatest thing I can think of is turn ops into a union and do some
more sophisticated form of getopts string processing. This increases
the stack usage for each execbuiltin() by some considerable amount,
however. We can probably do something with the value of the individual
option value. Currently 2 is used for turning off with `+', but scope
for something more.
--
Peter Stephenson <pws@xxxxxxx> Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK Tel: +44 (0)1223 392070
**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential
and/or privileged material.
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by
persons or entities other than the intended recipient is
prohibited.
If you received this in error, please contact the sender and
delete the material from any computer.
**********************************************************************
Messages sorted by:
Reverse Date,
Date,
Thread,
Author