dunstrc rule filter syntax change

[bynect]

One of the milestones for dunst v2 is an overhaul of the rule syntax for better consistency.

See #1333 and #349

TLDR: we want to change the (arbitrary) name of the rule filters and setters to a consistent style.
For example
msg_urgency & urgency -> set_urgency & match_urgency
new_icon & icon -> set_icon & match_icon
...etc

That said, I am not sure if to use match_ or not. What is your opinion as a dunst user?

[ValdezFOmar]

I think that match_ conveys the intention better, has sounds more like the condition is in the existence of the property (does it have or not this property?) while match sounds more like the condition is in its value (does the property matches this value?).

[bynect]

thanks for the feedback

[bynect]

@fwsmit @zappolowski @bebehei sorry to bother, could you tell me your idea on this

[bynect]

I am willing to start implementing the changes to the rule parser, but I think it could be a bit big so we should release before that?

[fwsmit]

What kind of changes do you suggest? Make match and set built in? Do we want to make it backward compatible? I think that it would not be too difficult to make it backward compatible, at l least until the next major version.

[bynect]

What kind of changes do you suggest? Make match and set built in? Do we want to make it backward compatible? I think that it would not be too difficult to make it backward compatible, at l least until the next major version.

I want to make an automatic parser that adds the match_ and set_ to all properties (in the rules). I can also issue some logging to ask people to switch to the new syntax. maybe for v2 we can remove the old syntax at all. but for the time being it will be backward compatible

[fwsmit]

Can you explain the advantage of the automatic parser?

[bynect]

Can you explain the advantage of the automatic parser?

so we can simply define the properties (urgency, color, title, etc) with their types and the parser handles automatically filter and setter syntad. so we can also provide a wider range of filter and setter without having to write adhoc documentation and parsing. this will also mean we can simplify the documentation on rules quite a bit