[Feature Request] Allow matching on individual categories

[Omar007]

Currently the criteria matching for category checks the whole category string but the notify-send man-page suggests supplying multiple using comma separation.

$ man 1 notify-send
...
-c, --category=TYPE[,TYPE...]
Specifies the notification category.
...

(fwiw, the same also applies to icon)

It would be nice if it was possible to define criteria on one or a combination of the defined comma-separated categories instead of handling it as one single big category.
E.g. for notify-send -c mycustom1,mycustom2,mycustom3 ..., sections [category=mycustom1], [category=mycustom2] and [category=mycustom1,mycustom3] would qualify. For configuration properties that exist in multiple, the most exact/complete match should take precedence (so in this example, the property set in the last one).

The matching part could potentially also/already be covered with #306 but as far as I understand things there is nothing like priority matching (I think it's currently just whatever matches first?) and since there is no ordering for the categories, setting up a regex to cover the different combinations would be a pain in the a** 😅

EDIT: Just saw the part in the man-page saying the last match will take so I suppose accounting for the ordering in your config file yourself would cover the priority matching by being smart about it.

[vilhalmer]

My reading of the spec says that this isn't actually a feature, but that you're just giving it a category of the literal name thing,thing2. That said, it would be extremely easy to make this one of the fields that you can do regex matches on.

[Omar007]

I can't find it explicitly stating in the spec if it is or isn't supported like it seems to suggest in the man-page and code. It is clearly all ending up in the category standard hint as a single string, that is definitely true, but at the same time it's also talking about categories (plural) in the spec.
While it is possible the man-page as well as the libnotify source code are just misleading in this regard and muddling the waters, both are suggesting it and neither (nor the spec) explicitly put a constraint anywhere that would make it impossibly for it to be a comma separated list of multiple individual categories. 🤷‍♂️
All of that said, I have not ever checked the source for other notification daemons so I don't know what the implementation details are like elsewhere. It could also be that it was indeed intended to work as described (comma separated list of categories) but that it is one of those things that just never really got finished up. Maybe this is a question for upstream first.

In regards to icon, for which it also suggested multiple items on the man-page, I find the spec to be quite clear about that one; the flag will set the icon-name hint and if you want an image to be displayed as well (assuming the notification daemon implementation supports both icons and images), that should instead be supplied through the hints image-data and/or image-path (first one taking priority).
Additionally, looking at the source code, it was cutting that command-line option off at the comma anyway so this only ever supported a single value and the man-page was wrong for this field. This also seems to be corrected/removed in March (GNOME/libnotify@dfaa761).

In regards to resolving this with supporting regex for this field, that would work for simple or cases. You could also maybe cover most combination cases as well assuming you keep things in the same order everywhere and those combinations don't cross with other combinations. Otherwise you need look-ahead (or -behind) and that isn't in the POSIX extended regex 🤔

[emersion]

I'm going to close this as "won't implement". The category is a string, so I'm fine with adding string matching operations, but I'd rather not split on commas.

Feel free to send a PR for regexp support.