From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by melb.werple.net.au (8.7.5/8.7.3/2) with ESMTP id AAA29467 for <mason@werple.mira.net.au>; Wed, 10 Jul 1996 00:27:07 +1000 (EST)
Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id KAA22749; Tue, 9 Jul 1996 10:07:04 -0400 (EDT)
Resent-Date: Tue, 9 Jul 1996 10:07:04 -0400 (EDT)
From: Zoltan Hidvegi <hzoli@cs.elte.hu>
Message-Id: <199607091406.QAA15086@bolyai.cs.elte.hu>
Subject: Re: Remaining zsh3.0-pre2 bugs
To: schaefer@nbn.com
Date: Tue, 9 Jul 1996 16:06:16 +0200 (MET DST)
Cc: A.Main@dcs.warwick.ac.uk, zsh-workers@math.gatech.edu
In-Reply-To: <960709020813.ZM30009@candle.brasslantern.com> from Bart Schaefer at "Jul 9, 96 02:08:11 am"
Organization: Dept. of Comp. Sci., Eotvos University, Budapest, Hungary
Phone: (36 1)2669833 ext: 2667, home phone: (36 1) 2752368
X-Mailer: ELM [version 2.4ME+ PL16 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"t66EW.0.NZ5.7Ucun"@euclid>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/1590
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

> } > But that doesn't work for completions with embedded newlines, even when
> } > a successful completion is possible:
> } 
> } It fails because zsh sees that the current word starts in the previous
> } already entered line.
> 
> Where's that happening?  Not in get_comp_string() ...

Certainly not.  The wb < 0 check does that what you have just deleted in the
patch you sent.

> 
> } In that case zsh simply gives up the completion
> } attempt, restores the original line and returns.
> 
> Why is that necessary?  Maybe it's necessary if the word *ends* in the
> previous line for some reason, but ...

The problem is that that:

% echo 'z'\
> l<TAB>

Here get_comp_string removes the quotes around 'z' but it does not work
since the already entered part cannot be modified.  The quotes have to be
removed for completing filenames.  This later causes a SEGV.

> Hmm.  Your patch does a couple of things.  One, it removes the loop that
> folds embedded newlines into semicolons; two, it attempts to save and

Yes, it seems that it is not necessary.  That mainly caused problems after
a backslash <newline>.  Perhaps that's the bug mentioned in Etc/BUGS.

> restore the cursor position.  There's one bogus compiler warning:
> 
> zle_tricky.c: In function `docomplete':
> zle_tricky.c:500: warning: `ocs' might be used uninitialized in this function
> 
> I cleared this by initializing ocs = 0 in the declaration.

gcc is wrong here but I agree that we have to make it happy.

> By the way, there are block-locals named ocs and ol used in various
> places in docomplete(), which could lead to confusion.  I didn't try
> to fix that, though.

I do not think that confusing.  These are just temporary variables.  And
ol/ocs always store some previous line/position so the usage is
consistent.

> Anyway, after the newlines-to-semicolons thing is removed, it doesn't
> seem to make any difference whether (wb < 0 || we < 0 || cs < 0).  I

This is still necessary and it is completely unrelated to the newlines to
semicolons change.  There was nothing wrong about converting unquited
newlines to semicolons.  It worked well.  But I removed it because I think
it is unnecessary.

Zoltan