Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: `try' syntax
- X-seq: zsh-workers 20051
- From: Oliver Kiddle <okiddle@xxxxxxxxxxx>
- To: Zsh hackers list <zsh-workers@xxxxxxxxxx>
- Subject: Re: PATCH: `try' syntax
- Date: Tue, 15 Jun 2004 12:31:20 +0200
- In-reply-to: <Pine.LNX.4.44.0406141015190.32342-100000@xxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <Pine.LNX.4.44.0406141015190.32342-100000@xxxxxxxxxxxxxxxxxx>
Bart wrote:
> * A "shortloops" form "try { ... }" might be nice, or maybe should be the
> only form.
Or, thinking along those lines, you could use something like
{ ... } always { ... }
That currently finds a syntax error at always.
> * Rather than putting colons or some other unlikely character in front of
> the name, use plain words and start with them "disable"d, so that in order
> to use this syntax one must first "enable -r try always tried". (This
> technique could apply to other extension syntax as well.)
That would be quite a good way of handling it. My main reservation
concerns the fact that it isn't possible to make the enabled/disabled
state of builtins local.
Consider _approximate. It'd be nice to use a try/always block to do the
job currently performed by a trap to unfunction compadd. So how do you
enable try and always but restore their original state when completion
exits. It's possible using the parameters module but would get fairly
messy. And we'd be wanting to re-disable `tried' from within an always
block.
Oliver
Messages sorted by:
Reverse Date,
Date,
Thread,
Author