Re: REMATCH_PCRE with zsh built without pcre support

[Bart Schaefer <schaefer@brasslantern.com>]

On Apr 3, 11:26am, Daniel Shahaf wrote:
}
} I agree that semantics of operators shouldn't depend on option

I'm not even particularly worried about semantic dependency; the gripe
here is that "setopt re_match_pcre" does not succeed (or fail) based on
the presence (or absence) of the module.  Exactly how big a problem is
that?  If you are relying on =~ having perl semantics, you ought to be
calling "zmodload zsh/pcre" anyway, and not just expecting setopt to do
that for you.

On the other hand if others think it's a major shortcoming that setopt
does not hard fail when the option won't actually have a useful effect,
then we should use a different paradigm than setopt here; yes it would
be possible for setopt to barf with "can't change option: rematchpcre"
but that means a module-specific special case that no other setopt has.

And now I've repeated myself at least three times so I'll stop.

} > [...] the zsh/regex module would have to become part of the default
} > static build, which might have licensing consequences.
} 
} What would those be?  zsh/regex is BSD licensed.

I don't know, and don't have time to figure it out.