Add support for PCRE

[fedang]

Glib exposes PCRE with GRegex. Since we already have the library lying around we might as well use it

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 95.45455% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 65.42%. Comparing base (a970a99) to head (cdb4036).

Files with missing lines	Patch %	Lines
src/rules.c	93.33%	1 Missing ⚠️
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1536      +/-   ##
==========================================
+ Coverage   65.37%   65.42%   +0.05%     
==========================================
  Files          51       51              
  Lines        8944     8957      +13     
  Branches     1069     1071       +2     
==========================================
+ Hits         5847     5860      +13     
  Misses       3097     3097              

Flag	Coverage Δ
unittests	65.42% <95.45%> (+0.05%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[fedang]

/extra-ci

[fedang]

@fwsmit let me know what do you think of this

[fwsmit]

I think it would be better to have a regex type config variable instead if multiple booleans that have an arbitrary priority.
What is the advantage of having two regex types in dunst? Is there not one that is the best?

[fedang]

I think it would be better to have a regex type config variable instead if multiple booleans that have an arbitrary priority.
What is the advantage of having two regex types in dunst? Is there not one that is the best?

The best is undoubtedly PCRE as it allows many things like negative matches, lookahead ecc. In an ideal world I would remove the posix regex boolean and just use this. However the config is literally called enable_posix_regex so it would be misleading to enable PCRE in my opinion. The idea was to add this new experimental flag and eventually remove enable_posix_regex (with proper docs).

So mainly it's backwards compatibility.
If we are willing to break it I can just make enable_posix_regex issue a warning and basically be an alias to enable_pcre_regex.

Another option is to add an option like match_flavour that could be any of fnmatch, regex, pcre, ecc. So that there are no arbitrary booleans. But anyhow the same breakage as the previous example is needed.

Let me know what do you think it's best moving forward

[fedang]

@dunst-project/developers thoughts?

[fwsmit]

Is pcre regex backward compatible with the current posix regex?

[fedang]

as far as I know it's not 100% backwards compatible. that's why I didn't silently upgrade enable_posix_regex to use GRegex implementation.

[bebehei]

Main difference between PCRE and non-PCRE is the escaping of braces. One needs to escape them to have special meaning, the other you have to escape to match a brace literal. This sucks. It's like a USB-A connector. Correct at the first third try.

For the rest, PCRE is mostly an upgrade.

---

BTW: you're allowed to release dunst 2.0 and drop the unwanted code. So you could drop ERE support here and switch to PCRE.

[fedang]

Main difference between PCRE and non-PCRE is the escaping of braces. One needs to escape them to have special meaning, the other you have to escape to match a brace literal. This sucks. It's like a USB-A connector. Correct at the first third try.

For the rest, PCRE is mostly an upgrade.

---

BTW: you're allowed to release dunst 2.0 and drop the unwanted code. So you could drop ERE support here and switch to PCRE.

Yes the idea was to provide "experimental" PCRE support and in v2 just phase out ERE.
Also I was thinking of dropping fnmatch alongside ERE, let me know if that would be too drastic. (Maybe I am a bit biased but regex seems just better than fnmatch)

[bebehei]

I thought fnmatch was the low hanging fruit available and enough. I expected PRCE/Regex would increase the footprint and therefore refrained from adding it. I wasn't aware it was basically free in GLib already.

Regex is for devs definitely more flexible, but more complex for entry level linux users.

You do the decision. I can go with both.