Re: Remaining zsh3.0-pre2 bugs

[Zoltan Hidvegi <hzoli@xxxxxxxxxx>]

> } 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?
> 
> get_comp_string() computes a "wrong" value for wb, we, and cs when the
> completed form of a word contains fewer characters than the original.
> That happens with backslash-newline, because "a\\\nb" becomes "ab" when
> parsed.  I may be following this wrong -- I'm not very familiar with the
> completion code -- but I think the seg fault results when wb or one of
> the others is decremented not just past the embedded newline (wb < 0),
> but back farther than the beginning of the previous line.

Not really.  If you complete after

% echo '****
> '

makecomplist() does a backdel() to replace the line to

% echo \*\*\*\*"
"

That will overwrite something before line in the memory.

> Define "work".  If I type tab immediately after the closing quote, it
> feeps and the line is not changed.  I believe that's because of the
> hunk at the end of my patch, `if (ol && !nmatches && (wb < 0 ...))',
> which restores the old line after discovering that the completion failed.

But the line should not be restored since

% echo '*'<TAB>

should give

% echo \*

and not

% echo *

I do not line you alternative solution as well which executes
push-line-or-edit because it is probably not very convinient for those
using single_line_zle.  I think it is not a big limitation that completion
does not work in this rare case.  Note that

% echo foo\
> bar zle_t<TAB>

works and gives

% echo foo\
> bar zle_tricky.c

Zoltan