Thanks for the feedback, Jack/Yonik.
1 - support for mixed-case operators is as before: they are interpreted as operators. Having said that, there appears to be an subtle bug with the 'mm' toggling behaviour. The operator counting (used to determine whether 'mm' needs to be disabled) only accepts strict uppercase and lowercase, whereas the query rebuild accepts mixed-case. I can also fix that up and add a test.
2 - the 'supportedLowercaseOperators' parameter would be in addition to 'lowercaseOperators', rather than replacing it. If 'lowercaseOperators' is true, we look for a 'supportedLowercaseOperators' value. If no value is provided, we use the default (and, or), which means we have backwards compatibility.
Yonik - yeah, Jan's proposal is absolutely the most flexible. I guess my concerns were:
- that it might snowball into wanting to have an external, stopword-esk file for per-language operator support (minor concern)
- that we'd lose some backwards compatibility, as currently mixed-case operators are supported (although the default set could be expanded to accommodate this, if needed)
- the interaction between the 'lowercaseOperators' parameter and 'valid*' might get a little funky. For example, if we simply ignore 'lowercaseOperators' when a 'valid*' parameter is present, there is no potential for confusion BUT toggling lowercase operator support per query then becomes a head-ache (as the upstream client needs to pass through the supported uppercase operators). If we allow interaction between 'lowercaseOperators' and 'valid*', which parameter takes priority? To allow toggling per-query, lowercaseOperators should take priority. Perhaps a good dollop of documentation would be enough here
Let me extend the patch to switch-over to Jan's proposal so people can take a look.