From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1112 invoked from network); 5 Jun 2000 08:05:09 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 5 Jun 2000 08:05:09 -0000 Received: (qmail 27266 invoked by alias); 5 Jun 2000 08:05:00 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11746 Received: (qmail 27259 invoked from network); 5 Jun 2000 08:04:59 -0000 Date: Mon, 5 Jun 2000 10:04:08 +0200 (MET DST) Message-Id: <200006050804.KAA03429@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 04:48:00 +0000 Subject: Re: Getting "parse error" from _path_files Bart Schaefer wrote: > Cut'n'paste the following into a zsh-3.1.7: > > echo "${(@)${(@s:|:)${(@)${(@f)$(< /etc/printcap)}:#[ \#]*}%%:*}%%[ ]*}" > > Note that inside each pair of [ ] are a space and a tab. > > I get, at each tab: > > _path_files:249: parse error > > This is mildly annoying, as it aborts completion without giving the system a > chance to clean up (e.g., it's another case where very bad things happen if > it is _complete_debug that's called). I vaguely recall forcing something > into a $(...) in some other completer to avoid a similar problem. > > There are actually two things at issue here. The second is that I'd rather > that completion didn't happen when I'm doing cut'n'paste. I tried putting: > > (( 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). > 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? > This would correspond to what happens when you use `eval', as in: > > function fail() { > local x y z > x='${y' > eval 'z=${(e)x}' > echo got here > z=${(e)x} > echo did not get here > } > > Alternately, of course, we could use `eval' on line 249 of _path_files and > in similar spots, but the quoting may sometimes get messy ... 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? Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de