On Tue, Dec 07, 2010 at 06:03:53AM -0800, Dan Nicholson wrote: > On Mon, Dec 6, 2010 at 5:45 PM, Peter Hutterer <[email protected]> > 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 <[email protected]> > >> 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. > _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
