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

[Peter Hutterer]

On Fri, Jun 03, 2011 at 09:22:42AM -0500, Dan Nicholson wrote:
> 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.

sounds sensible.

> 
> > - 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.

I think there's a misunderstanding: my suggestion is to only expose to users
the native (current) match mode (which may be fnmatch in the case of
MatchDevicePath) and regex. 

If a user needs fnmatch on MatchProduct, then they're out of luck, they'll
have to try to find a regex that provides that behaviour.

What we do internally is a different matter of course, and that's where we
should use whatever is simplest.

Cheers,
  Peter

> > - 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
>