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 FAA13410 for <mason@werple.mira.net.au>; Thu, 11 Jul 1996 05:58:05 +1000 (EST)
Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id PAA09453; Wed, 10 Jul 1996 15:48:37 -0400 (EDT)
Resent-Date: Wed, 10 Jul 1996 15:48:37 -0400 (EDT)
From: Zoltan Hidvegi <hzoli@cs.elte.hu>
Message-Id: <199607101948.VAA29276@bolyai.cs.elte.hu>
Subject: Re: Remaining zsh3.0-pre2 bugs
To: schaefer@nbn.com
Date: Wed, 10 Jul 1996 21:48:01 +0200 (MET DST)
Cc: zsh-workers@math.gatech.edu
In-Reply-To: <960710121111.ZM4060@candle.brasslantern.com> from Bart Schaefer at "Jul 10, 96 12:11:09 pm"
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: <"LTXNp.0.dJ2.Ka0vn"@euclid>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/1601
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

> } > } 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.
> 
> Well, then, why not catch that special case (backslash-newline) and let
> other cases of embedded newlines keep working?  Patch below.

It did not study your patch too much so perhaps I just do not see something
obvious but I do not understand what is this wb < (oll - ll) check?

But not only backslash-newline is the problem.  It was just an example.
Try completing after

% echo '***
> ***'

Does it work with your patch?  Here makecomplist() wants to modify the
line.  Note that my patch does not completely disables completion after a
backslash-newline.  It just disables it when the current word starts in an
already entered line.  And even in that case completion is possible after
executing push-line-or-edit.  It is seems that it's not easy to correctly
handle this special and it does not worth it since it occurs very rarely.

> There's one other bug that this patch does NOT address; and maybe it's not
> a bug at all.  However, here's the example:
> 
> zagzig<6> touch cegi efgh
> zagzig<7> echo c'e<TAB>
> zagzig<7> echo c'efgh
> 
> If I do it with TWO quotes (I don't have rcquotes set):
> 
> zagzig<8> echo c''e<TAB>
> zagzig<8> echo cegi
> 
> zagzig<9> echo c'e'<TAB>
> zagzig<9> echo cegi
> 
> And yet:
> 
> zagzig<10> echo c'e'<C-b><TAB>	<-- Complete inside second quote
> zagzig<10> echo c'efg '		<-- Cursor ends on second quote

When you inside a quoted string zsh assumes that the word begins after the
quote and ignores the part of the word before the quote.  In fact the
quotes is treated as a space in that case.

Zoltan