From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9928 invoked from network); 7 Jul 1999 10:13:01 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 7 Jul 1999 10:13:01 -0000 Received: (qmail 8122 invoked by alias); 7 Jul 1999 10:12:52 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7001 Received: (qmail 8115 invoked from network); 7 Jul 1999 10:12:47 -0000 Message-Id: <9907070944.AA35111@ibmth.df.unipi.it> To: zsh-workers@sunsite.auc.dk (Zsh hackers list) Subject: Re: PATCH: pws-25: another line number problem In-Reply-To: "Peter Stephenson"'s message of "Wed, 07 Jul 1999 10:56:23 DFT." <9907070856.AA40613@ibmth.df.unipi.it> Date: Wed, 07 Jul 1999 11:44:02 +0200 From: Peter Stephenson Peter Stephenson wrote: > Consider: > > % fpath=(.) > % cat alf > [[ foo bar ]] && print That did\'t work > > # > print foo > % autoload alf > % alf > alf: parse error: condition expected: foo [5] > > The line number reported is the last line of the file. The answer, > thankfully, is simple: don't flush the input queue until the error message > has been printed. Gag. Now I've found out why the error had to come second: if errflag is set, history flushing won't work, so if the parse error occurred interactively, you don't get the rest of the line in the history. Let's just try something like my other proposal: don't do a full history flush if reading from a string. This *replaces* the previous patch. --- Src/hist.c.uln2 Thu Jun 17 14:22:18 1999 +++ Src/hist.c Wed Jul 7 11:39:09 1999 @@ -291,7 +291,7 @@ void herrflush(void) { - while (!lexstop && inbufct) + while (!lexstop && inbufct && !strin) hwaddc(ingetc()); } -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy