Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Getting "parse error" from _path_files
- X-seq: zsh-workers 11751
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: Getting "parse error" from _path_files
- Date: Mon, 5 Jun 2000 16:33:39 +0200 (MET DST)
- In-reply-to: "Bart Schaefer"'s message of Mon, 5 Jun 2000 14:21:30 +0000
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
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@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by:
Reverse Date,
Date,
Thread,
Author