The current "allow_markup" setting will simply strip any markup from the final
notification, which includes formatting elements. On top of that, literal
[<>&..] symbols are not quoted before are being passed onto pango in several
places, resulting in stray error messages.
This patch fixes allow_markup to correctly strip markup only from the incoming
notification, not from the format.
You might also want to treat incoming messages as literal text (supplied by
un-aware programs), in which case you need to properly quote the text before
it's processed by pango. A new setting is introduced, called "plain_text",
which forces incoming messages to be treated literally.
allow_markup/plain_text are complimentary to each other.
The new rule actions allow to narrow down the handling to a specific block,
achieving notification Zen.
The following is done in this patch:
- Fix ruleset initialization in config.def.h.
- Introduce new allow_markup/plain_text actions in the rules.
- Fix handling of allow_markup to strip markup from summary/body only,
preserving format's markup.
- Fix broken string functions (string_replace_all didn't handle recursive
replacements correctly).
- Fix quoting of other literal fields (icon name/appname).
- Fix handling of ignore_newline as well (applied only on summary/body).
- Dunstrc update with the same previous defaults.
The manual for g_variant_iter_next_value states the following:
"[..]
Use g_variant_unref() to drop your reference on the return value when
you no longer need it.
[..]"
https://developer.gnome.org/glib/unstable/glib-GVariant.html#g-variant-iter-next-value
For most notifications (I guess), this is not a problem, since the leak
is relatively tiny. However, for notifications that contain big chunks
of binary data, such as those sent out by the new Spotify client, it
adds up fast.
The Spotify notifications in particular contain a rather large
"icon_data" byte array (contained in a dict), which while never recorded
is never-the-less iterated over and allocated, which in turn gives rise to
issue #173.
This fixes#173.
