Re: zsh-3.1.2-zefram4

[Andrew Main <zefram@xxxxxxxxx>]

Peter Stephenson wrote:
>The idea was that with the ksh and zsh models being incompatible
>anyway, it was asking for trouble trying to mix them.

If we add an unambigous syntax for qualifiers, it will be possible to
mix them.  Anyway, I simplified the code, as well as the documentation,
quite a bit.

>?? It didn't have any semantics before, it didn't work at all inside
>parentheses.

It works just as well as *~, unless I'm missing a critical test case.
As I mentioned earlier, there's a serios bug in ~ processing.

>but what's wrong with the meaning `negate the following' that it needs
>the extra parentheses?

Precedence.  ^ binds tighter than /, | and so on.  ~ binds looser than
anything except |.  You made a ^ immediately after a ( bind looser
than *anything*, which made "(^foo|bar)" and "((|)^foo|bar)" behave
differently.

>> This turned up a very old
>> bug in the exclusion handling: `(foo~bar)BAZ' is actually treated as
>> `fooBAZ~barBAZ', rather than the exclusion being properly localised.
>
>?????? How could it possibly mean anything else?

It matters when what follows the parentheses has more than one way to
match.  This includes the case of having two negations in the pattern or,
and this is the killer, a negation inside a loop.  Consider "(*~foo)b*"
versus "*b*~foob*" -- "foobb" should match the former ("foob" matches
"(*~foo)") but not the latter.

-zefram