Transitioning rules to a more consistent naming scheme

[tsipinakis]

Rules are currently named in a very unpredictable matter in a way that one cannot easily distinguish between filter/match rules and actions. As an example msg_urgency is used to match the urgency and urgency to override it. This is probably because at the start the attributes that could be matched were different than the attributes that could be overridden (i.e. matching on appname, body etc and overriding attributes like timeout or format).

To fix that, I'd propose migrating to a much simpler naming scheme using match_ and set_ prefixes.

As an example the current matching rules would look like this:
match_appname, match_summary, match_urgency

And the assigning actions as follows:
set_timeout, set_urgency, set_foreground, set_background, set_icon and set_format

[bebehei]

Are there any words which represent match and set and have an equal length? For the readability in your dunstrc this might be a very good choice.

[bebehei]

Are there any words which represent match and set and have an equal length?

I would propose has_ and set_:

[critical]
    has_body = "backup failed"
    has_summary = "backup"
    
    has_urgency = "normal"
    set_urgency = "critical"

[WhyNotHugo]

I've been thinking rules could have a much more english-like format, something like:

match message "backup failed" set urgency "critical"
match message "backup successful" set urgency "normal"
match message "backup something else" set transient on

The language for this is basically:

match [condition value]+ set [attribute value]+

This is really based on pf and opensmtpd's syntax format, which are really readable.

The upsides are:

• One line/statement per rule.
• Much more readable.
• Extendable
• Large amount of rules are easier to handle [when maintaining a conf file[.

Downsides:

• Not an ini-like format.
• Parser may be slightly more non-trivial

[tsipinakis]

If we're going to go this far with the matching logic, we might as well implement a full on filter language like newsbeuter.

One line/statement per rule.

I'm not sure this is an upside, having an option for a rule to be a single line would be good, but for a more complicated rule with multiple matches and assignments it can be much better to split it over multiple lines.

Not an ini-like format.

This is a big downside, it breaks the current configuration format meaning that the config parser will have to be reworked and that it breaks the ability for external tools to parse the config file if needed (for example I was just looking into using pythons ini capability to attempt to write a script to generate test cases).

One workaround to this (albeit a bit ugly) might be to split rules into a different file(e.g. dunst.rules).

[WhyNotHugo]

I'm not sure this is an upside, having an option for a rule to be a single line would be good, but for a more complicated rule with multiple matches and assignments it can be much better to split it over multiple lines.

Yeah, the main point was once statement per rule.

[tsipinakis]

There hasn't been any work done for this and haven't really decided yet how to handle it. I'm bumping this to 1.5.