Re: Getting "parse error" from _path_files

["Bart Schaefer" <schaefer@candle.brasslantern.com>]

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