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

[Peter Hutterer]

On Tue, Dec 07, 2010 at 06:03:53AM -0800, Dan Nicholson wrote:
> On Mon, Dec 6, 2010 at 5:45 PM, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> > 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.
> 
> I don't think using regular expressions for everything is wise for a
> couple reasons.
> 
> 1. We already have configurations out there that use the boring strcmp
> and strstr matches. Silently treating those as regexes will break
> strings that have any of ".*?()[]".
> 
> 2. We already have configurations out there that use fnmatch globbing.

both could be handled by enforcing a delimiter
  MatchProduct "pattern"    # normal match as before
  MatchProduct "s/pattern/" # fancy regex match

but I guess that comes back full circle to needing to specify types :)

I like your idea of specifying the library call, at least there's no
ambiguity over what happens behind the scenes and plenty of documentation
available if in doubt.

Cheers,
  Peter

> There's no easy conversion between regexes and globs. I was on the rpm
> mailing list a couple years ago, and the maintainer had an anecdote
> about a situation like this. If you run "rpm -qa <pattern>", the
> pattern was heuristically treated as either a glob or a regex based on
> the characters. He did this because it was originally a regex, but too
> many people didn't understand how regexes worked. I turned out most
> people understood globs much better, so he put some magic in the code
> to try to have both. He said he always regretted that decision and
> wished he'd just picked one or the other. I would wager that most
> people would rather have globbing for paths.
> 
> > 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.
> 
> These aren't X specific, though. They're all standard (to differing
> extents) C library calls. They're just strcmp, strcasecmp, strstr,
> strcasestr and fnmatch. I tried to give them "useful for
> non-programmer" names, but we can refer to them by their symbol names
> if that's clearer. regex(3) is also entirely standard, but we didn't
> have any use for them yet.
>