Re: Remaining zsh3.0-pre2 bugs

[Zoltan Hidvegi <hzoli@cs.elte.hu>]

> } > 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