On Fri, Jun 03, 2011 at 09:22:42AM -0500, Dan Nicholson wrote: > On Fri, Jun 3, 2011 at 1:30 AM, Peter Hutterer <[email protected]> > wrote: > > On Thu, Jun 02, 2011 at 05:53:14PM +0300, Oleh Nykyforchyn wrote: > >> Please consider a final version of the patch. > >> > >> ------------------------------- > >> > >> Multiple matching modes selection (incl. regex) support in Match* > >> statements > >> > >> Any number of patterns can be written in one line either as > >> MatchProduct "foo|!bar" "something|re:^else$" "you" "!regex:n..d" > >> or as > >> MatchProduct "foo" "!bar|something" "regex:^else$" "you|!re:n..d" > >> etc. A regex ends at the end of the respective "piece", irrespective of > >> '|'s. > >> > >> Regexes are prefixed by "regex:" of "re:", prefixes are also added for all > >> other matching modes in two versions each: short and real name of the used > >> function. Negated conditions are prefixed by "!", which can be combined > >> with > >> each other prefix. Different modes, as well as usual and negated patterns, > >> can be mixed in one line. > > > > whoa, this was a bit scary to look at at first :) > > a few high-level comments, the patch itself looks sane on a first glance. > > - let's just use "regex:", not either of "regex:" or "re:". one is enough. > > - I'm not a big fan of allowing a mix of multiple arguments and |. We could > > just require escaping | in a regex so that the result is a > > MatchProduct "foo|!bar|regex:^blah$|regex:a\|b" > > imo this is much easier to read than a multi-argument mix like your two > > examples above. > > 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. 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 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.
sounds sensible. > > > - 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. 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. I think there's a misunderstanding: my suggestion is to only expose to users the native (current) match mode (which may be fnmatch in the case of MatchDevicePath) and regex. If a user needs fnmatch on MatchProduct, then they're out of luck, they'll have to try to find a regex that provides that behaviour. What we do internally is a different matter of course, and that's where we should use whatever is simplest. Cheers, Peter > > - 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. > > Sorry to be harsh, but I'm having a hard time seeing how these > proposals will improve the situation and not break current setups. > > -- > Dan > _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
