>You could avoid (some of?) these problems by supporting /(?i)foo/ instead of /foo/i
That would avoid our parsing dilemma but brings some other concerns. This inline syntax can normally be used to selectively turn on case sensitivity for sections of a regex and then turn it off with (?-i). We could potentially implement this support in the underlying o.a.l.util.automaton.RegExp class. We changed that class recently to take a separate global flag alongside the regex string which can determine case sensitivity. I guess any inline (?i) syntax would override whatever default option had been passed in the constructor flag. That might be a hairy change though - the RegExp parser logic is hand-crafted rather than JavaCC. On Fri, Sep 18, 2020 at 7:47 AM Dawid Weiss <[email protected]> wrote: > > If they try to use any other options then 'i' we throow a ParseException > > +1. Complex-syntax parsers should throw (human-palatable) exceptions > on syntax errors. A lenient, "naive user" query parser should be > separate and accept a very, very > rudimentary query syntax (so that there are literally no chances of > making a syntax error). > > D. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
