From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4813 invoked from network); 15 Jun 2004 20:21:55 -0000 Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.86) by ns1.primenet.com.au with SMTP; 15 Jun 2004 20:21:55 -0000 Received: (qmail 27362 invoked from network); 15 Jun 2004 20:21:38 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 15 Jun 2004 20:21:38 -0000 Received: (qmail 3272 invoked by alias); 15 Jun 2004 20:21:34 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 20054 Received: (qmail 3262 invoked from network); 15 Jun 2004 20:21:33 -0000 Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (qmailr@130.225.247.86) by sunsite.dk with SMTP; 15 Jun 2004 20:21:30 -0000 Received: (qmail 27102 invoked from network); 15 Jun 2004 20:21:30 -0000 Received: from moonbase.zanshin.com (root@64.84.47.139) by a.mx.sunsite.dk with SMTP; 15 Jun 2004 20:21:28 -0000 Received: from toltec.zanshin.com (toltec.zanshin.com [64.84.47.166]) by moonbase.zanshin.com (8.12.11/8.12.11) with ESMTP id i5FKLPuD022198 for ; Tue, 15 Jun 2004 13:21:25 -0700 Date: Tue, 15 Jun 2004 13:21:25 -0700 (PDT) From: Bart Schaefer To: Zsh hackers list Subject: Re: PATCH: `try' syntax In-Reply-To: <200406151333.i5FDX275000620@news01.csr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, hits=0.0 required=6.0 tests=none autolearn=no version=2.63 X-Spam-Hits: 0.0 On Tue, 15 Jun 2004, Oliver Kiddle wrote: > Bart wrote: > > * 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. Hmm, good point. You'd have to do something like enable try always tried try # ... always disable try always tried tried (which should work, because the entire "try ... tried" must be parsed before the disable executes), but one would also have to store the initial state of the keywords and then test whether to disable them. > 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. Maybe the "enable" command should have a -L option like "emulate", that works like "setopt localoptions". There could even be an option for it, "localenable". (This begs the question of whether "localdisable" is a synonym or ...) > It's possible using the parameters module but would get fairly messy. Hmm ... wouldn't local -a +h reswords dis_reswords cover all possible cases? (Hmm, again; no, it seems it does not, because either the values aren't restored and/or assigning to these arrays doesn't accomplish enable/disable. Odd, but oh, well.) On Tue, 15 Jun 2004, Peter Stephenson wrote: > Bart Schaefer wrote: > > * A "shortloops" form "try { ... }" might be nice, or maybe should be the > > only form. > > It's rather nonstandard. So is the whole "try" concept, at least for shells. > Oliver wrote: > > Or, thinking along those lines, you could use something like > > { ... } always { ... } > > That currently finds a syntax error at always. > > Syntactically, it's still a bit tricky. Either `always' is a keyword, > or it isn't. Not unprecedented; "in" behaves like a keyword in certain positions, but is not one. > The other part is that we don't know till we get to the `always' > whether there is an always present. Possibly it could just be > tacked onto ordinary current-shell structures. In the case of "in" there's always an introducer ("case", "for", etc.), which would argue for leaving the "try" somewhere. On a different tangent, maybe the whole thing should parse more like "coproc" does, and perhaps "always" should be replaced with something like the ";&" from "case". > As things stand I'm not sure I'm going to have any free time before > 2008, but if I do is this worth trying? (In other words, is it > reasonably agreeable to everyone interested?) It's definitely getting close.