From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3224 invoked from network); 5 Jun 2000 14:34:47 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 5 Jun 2000 14:34:47 -0000 Received: (qmail 467 invoked by alias); 5 Jun 2000 14:34:40 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11751 Received: (qmail 459 invoked from network); 5 Jun 2000 14:34:38 -0000 Date: Mon, 5 Jun 2000 16:33:39 +0200 (MET DST) Message-Id: <200006051433.QAA04873@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Mon, 5 Jun 2000 14:21:30 +0000 Subject: Re: Getting "parse error" from _path_files Bart Schaefer wrote: > 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? Err...? It is tested for being set (to true), with different defaults for not-in-vared and in-vared. > } > 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. No time now... maybe I'll be able to do that this evening (I'll then make it behave like (Q), etc). Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de