[PATCH] xfree86: Allow InputClass entries to specify match type

[Peter Hutterer]

On Mon, Dec 06, 2010 at 05:47:02AM -0800, Dan Nicholson wrote:
> On Sun, Dec 5, 2010 at 9:29 PM, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> > On Thu, Dec 02, 2010 at 06:19:15AM -0800, Dan Nicholson wrote:
> >> The InputClass Match* entries are currently hardwired to offer a certain
> >> variant of comparison for matching. For example, the MatchProduct entry
> >> uses substring match. Add a second optional argument to the entry to
> >> allow the match type to be specified.
> >>
> >>       MatchProduct "foo*" "pattern"
> >>
> >> The available match types are "string", "istring", "substring",
> >> "isubstring", "path" and "pattern". See xorg.conf(5) for more details.
> >> If no type is supplied, the previous default is used.
> >
> > I wonder if it is possible to support sed- or grep-like matching instead of
> > adding match types like this?
> >
> > something like?
> >    MatchProduct "s/pattern/i"
> 
> Thanks for taking a look at this.
> 
> That would work, but it wouldn't offer the same flexibility. You'd
> basically get the default or an unusual regex. I personally think it's
> cleaner to specify the type (if you want), but I realize this is sort
> stretching it as a feature.
> 
> One of the things I intended to do was add a regex matcher. E.g.,
> 
>     MatchProduct "TheMouse[123]" "regex"
> 
> I can work on that now if it makes this patch seem more useful.

well, my thought was mainly that this may allow us to re-use a library that
provides this matching pattern already.

afaict, the examples you have above are "s/^string$/", s/^string$/i,
s/string/, s/string/i, (don't know about path) and s/..regex../. this is a
pretty standard way of specifying match patterns, there's plenty of
documentation for sed out there already, etc.

my worry is that we'll come up with something else that's X specific, and
then two releases down that's not quite enough either and we eventually end
up with a re-implementation of sed or grep anyway, except that we then also
have to support istring, qstring, [a-z]substring, etc.

Cheers,
  Peter