Re: vim completion problem after workers/35168

[Peter Stephenson <p.stephenson@samsung.com>]

Bart Schaefer wrote on Mon, May 18, 2015 at 17:30:34 -0700:
> Hrm.  Zsh patterns include "(this|that)", and "case" syntax includes
> "pattern)" without an open paren, so ...?

The problem is that the initial "(" now has to introduce a set of words
(with whitespace that's optional in most but not all cases) rather than
a single zsh pattern.  If you find an extraneous ")" at the end it's too
late to decide you should have been parsing a single pattern rather than
a set of alternative patterns.  We got away with this before by hacking
the pattern ex post facto in one case but not the other.

We could in principle read it as before and re-parse it, but that's
creating a bug-prone mess to fix a case I doubt happens very often (the
_vim code was clearly intended to have balanced parentheses all along).

> The "old hack" is one of those "well, it really should have been done
> differently in the first place, but it wasn't, so now what?" issues
> that bug me because *somebody* is going to get bitten in the way _vim
> just was.

Yes, we're in rather a corner over this.  But I'm still hoping the nasty
cases can be kept to a minimum.

On Tue, 19 May 2015 01:34:57 +0000
Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Is there any case in which the neither pre-35168 code nor post-35168
> code gives a parse error, but the semantics are different?

To the best of my knowledge the new code is stricter.  When I get a
moment to look, any laxness I introduce should be exactly on the lines
of what happened before --- I don't think there's any ambiguity because
after a string either you get a "|" (standard) or another string (zsh
special).

pws