From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3171 invoked from network); 5 Jun 2000 14:24:48 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 5 Jun 2000 14:24:48 -0000 Received: (qmail 27413 invoked by alias); 5 Jun 2000 14:22:13 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11750 Received: (qmail 27406 invoked from network); 5 Jun 2000 14:22:10 -0000 From: "Bart Schaefer" Message-Id: <1000605142130.ZM25433@candle.brasslantern.com> Date: Mon, 5 Jun 2000 14:21:30 +0000 In-Reply-To: <200006050804.KAA03429@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: Getting "parse error" from _path_files" (Jun 5, 10:04am) References: <200006050804.KAA03429@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Re: Getting "parse error" from _path_files MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 5, 10:04am, Sven Wischnowsky wrote: } Subject: Re: Getting "parse error" from _path_files } } Bart Schaefer wrote: } } > (( PENDING )) && compstate[insert]=tab } > } > near the top of _main_complete, right after curcontext is set up, and that } > seems to help a bit, but I'm rather leery of that solution. It does need } > to use PENDING somehow, though. } } It should then immediately return, too (to really avoid calling all } that completion code). Actually, it does return immediately, because of: if [[ "$compstate[insert]" = tab* && "$WIDGET" != *list* ]]; then { zstyle -T ":completion:${curcontext}:" insert-tab && { [[ "$curcontext" != :* || -z "$compstate[vared]" ]] || zstyle -t ":completion:vared${curcontext}:" insert-tab } } && return 0 Which reminds me to wonder why insert-tab is tested for *not* being set, at that point? } > Returning to the original issue: Perhaps it would be possible to special- } > case parsing within ${(e)...} so that errors of this sort simply return an } > empty value for the parameter rather than aborting the whole call chain? } } How about a parameter flag, the opposite of `X', but used for `e' to } make it ignore parse errors and return an empty string in such cases? } } Or make `e' not report errors normally and use `X' for `e', too, to } make it report errors? I'd forgotten about (X); yes, I think the latter (have (e) ignore errors unless (X) is given) is the right solution. It doesn't even have to ignore the errors silently; redirecting 2> is fine. It just has to not abort the surrounding parse. -- 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