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

[Oleh Nykyforchyn]

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.

> 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