[PATCH xserver] Multiple matching modes (incl. regex) selection support in Match* statements

[Dan Nicholson]

On Fri, Jun 3, 2011 at 1:30 AM, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> On Thu, Jun 02, 2011 at 05:53:14PM +0300, Oleh Nykyforchyn wrote:
>> Please consider a final version of the patch.
>>
>> -------------------------------
>>
>> Multiple matching modes selection (incl. regex) support in Match* statements
>>
>> Any number of patterns can be written in one line either as
>>       MatchProduct "foo|!bar" "something|re:^else$" "you" "!regex:n..d"
>> or as
>>       MatchProduct "foo" "!bar|something" "regex:^else$" "you|!re:n..d"
>> etc. A regex ends at the end of the respective "piece", irrespective of '|'s.
>>
>> Regexes are prefixed by "regex:" of "re:", prefixes are also added for all
>> other matching modes in two versions each: short and real name of the used
>> function. Negated conditions are prefixed by "!", which can be combined with
>> each other prefix. Different modes, as well as usual and negated patterns,
>> can be mixed in one line.
>
> whoa, this was a bit scary to look at at first :)
> a few high-level comments, the patch itself looks sane on a first glance.
> - let's just use "regex:", not either of "regex:" or "re:". one is enough.
> - I'm not a big fan of allowing a mix of multiple arguments and |. We could
>  just require escaping | in a regex so that the result is a
>      MatchProduct "foo|!bar|regex:^blah$|regex:a\|b"
>  imo this is much easier to read than a multi-argument mix like your two
>  examples above.

Even though I've argued repeatedly that having an additional argument
is the way to go, I would agree that an arbitrary amount of arguments
doesn't make this easier to understand. However, I think this will get
much more complicated if you want to get into the escaping game. Then
you're building a full out parser instead of just strtok and strncmp.

I think the only simple (to code and to understand by the user) is
just to say that you can either have a simple match separated by '|'
or a regex match. If you need both, you need a new InputClass section.

> - I don't think we should expose the multi-match modes. As I said in a
>  previous email - if we have true regex support I think we can emulate all
>  of them with a regex. fnmatch etc. will still need to be used internally
>  for the native matching mode.

I would strongly suggest that we not try to emulate simple matches
with regex. Are you going to try to escape all the special characters
before passing to regcomp? That again puts you in the land of building
your a parser. I'd argue wrapping strcmp/strstr/etc to make the return
codes match is far simpler than trying to get regex to match their
behavior. And if you're arguing that keeping fnmatch is necessary,
then you already have to separate regex from non-regex.

> - man page additions please

Agree completely here. This is getting pretty complex, and I'm really
curious to see it explained in a manual for people coming in fresh.

Sorry to be harsh, but I'm having a hard time seeing how these
proposals will improve the situation and not break current setups.

--
Dan