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

[Peter Hutterer]

On Fri, Jun 03, 2011 at 06:18:28PM +0300, Oleh Nykyforchyn wrote:
> On Fri, 3 Jun 2011 09:22:42 -0500
> Dan Nicholson <dbn.lists at gmail.com> wrote:
> 
> > 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.
> If we propose the syntax
>     MatchProduct "foo" "bar" "regex:a$|^b" "anything"
> which is notning new, see
>     Modes "640x480" "600x800" "768x1024"
> as _recommended_, say that matching ANY of the patterns is sufficient,
> and _allow_ to glue non-regex parts via '|', everything will be clear.

how is MatchProduct "foo" "bar" "regex:a$|^b" "anything" different from
MatchProduct "regex:foo|bar|a$|^b|anything"? AIUI, they should be the same
anyway.

The only case where this can bite us is MatchDevicePath and the ones thaking
shell patterns which can be rewritten in regex. Backwards compatibility is
important, but we do not need to provide full backwards compatibility for
those adding new features.

i.e. we need to make sure that existing MatchProduct "foo" continue to
work, but we can require users to alter that pattern if they want to add
regex: patterns.

Cheers,
  Peter

> > 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 agree, escaping '|' doesn't help here.
> > 
> > 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 thing that it is a good thing to say simply "accept RE1 and those RE2
> that does not match RE3" without multiplying "InputClass" sections.
> 
> > 
> > > - 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.
> Neither Peter nor I have said nothing about emulating simple mode internally.
> It was meant that regex helps if simple mode is insufficient. 
> 
> > 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.
> OK, I'l try.
> 
> > 
> > Sorry to be harsh, but I'm having a hard time seeing how these
> > proposals will improve the situation and not break current setups.
> Could You show some realistic setup examples that can be broken by
> these proposals?
> 
> Oleh