[PATCH 2/3 v2'] xserver: Introduce negated conditions in Match patterns

Dan Nicholson dbn.lists at gmail.com
Fri Jun 17 13:56:27 PDT 2011


On Fri, Jun 17, 2011 at 12:48 PM, Oleh R. Nykyforchyn
<oleh.nyk at gmail.com> wrote:
> On Fri, 17 Jun 2011 08:44:58 -0700
> Dan Nicholson <dbn.lists at gmail.com> wrote:
>
>> This is really confusing. I think it says that if the pattern didn't
>> match the attribute and the pattern was preceded by !, then we keep
>> going even though it successfully matched what we asked for.
> Yes, "!pattern" is a necessary, not a sufficient condition.
>
>> Is this
>> the "last pattern" thing?
> Last "!pattern" is sufficient. This exception allows us to treat
>    MatchProduct "!Mouse"
> as "all but mice".

Why wouldn't that work the way I described? If my product name is
"Keyboard", then it will match "!Mouse" and the MatchProduct will be
successful.

>> Why don't we break when match = TRUE?
>> Assuming I've understood this correctly, I think it breaks how the
>> current match rules are supposed to work.
> It contradicts to treating of "|" as "or". The only existing rule (if it can be called a rule)
> is "any match is sufficient".

I think "or" and "any match is sufficient" are equivalent. So, the "|"
does mean "or" right now.

>>
>> MatchProduct "foo|bar"
>> If the product name matches "foo" or "bar", use the class.
>>
>> MatchProduct "foo"
>> MatchProduct "bar"
>> If the product name matches "foo" and "bar", use the class.
> Correct
>>
>> Following that logic, I would expect this:
>>
>> MatchProduct "!foo|!bar"
>> If the product name does not match "foo" or does not match "bar", use the class.
> No, and this is one of reasons why I suggest
>      MatchProduct "!foo" "!bar"
> Here '|' is just a token separator, not logical "or". Hence the former is equivalent to

I think that would make things more confusing for people because the
behavior changes when you start using negation.

>> MatchProduct "!foo"
>> MatchProduct "!bar"
>> If the product name does not match "foo" and does not match "bar", use
>> the class.
>
>> I think you're trying to make the former act like the latter because
>> that's what you'd typically want to do with negated conditions.
> Yes
>
>> Rather
>> than making the code goofy, I'd rather have people use the correct
>> logic. I think it could be really simple:
> It is really simple, but less useful. I suggest "!foo" to filter out all attributes with
> "foo" except those that were accepted before.  Thus we can demand
>    MatchProduct "good|!goo"
> and get "only good of all goo". If "|" is "or", this is impossible.

Using the existing logic, this would just be:

MatchProduct "good"
MatchProduct "!goo"

What about that is less useful? What usefulness is added that makes
changing the behavior in subtle ways worth it?

--
Dan


More information about the xorg-devel mailing list