Re: Remaining zsh3.0-pre2 bugs

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Jul 10,  9:48pm, Zoltan Hidvegi wrote:
} Subject: Re: Remaining zsh3.0-pre2 bugs
}
} > } 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?

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.

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

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.

However, I now see that I didn't consider the case of completion after
something unusual like:

% *\
> *

This can still end up writing to (*(line - 3)) in makecomplist().  I'm
beginning to think the problem is not with completion per se, but with
expansion (and therefore with compctls that use -U).  Also, nmatches is
never set with expansions, so my `if (ol && !nmatches ...)' test isn't
accurate if expansion is all that occurs.

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

OK; I give up, for now.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"