C++ version: {message} contains more than that

[dgw]

I tried being very specific about my push notification format in my configuration, specifying exactly how I want the notification title to look, and how I want the body to look:

[00:38:31] <*push> | message_content        | <{nick}> {message}             |
[more irrelevant stuff]
[00:38:31] <*push> | message_title          | {network}/{context}            |

My configuration for message_title works beautifully; I get titles like "freenode/#znc" just the way I want. But message_content doesn't behave as expected. Instead of <jreese> if you're using the python version, I get <jreese> #znc: [jreese] if you're using the python version.

Clearly {message} contains more than just that. But when I poked through the code to see if there was another expansion keyword I could use instead, I came up empty.

I'd like to fix it, but am unsure if this is intended behavior. If {message} is supposed to contain the extra details, I'd like to create a PR to add {message_text} (name up for debate) so one can place only the message text somewhere in a notification, without the context and nickname attached automatically. If {message} is not supposed to contain the extra details, I'd like to create a PR to correct its behavior.

[amyreese]

I've noticed this in the past, and fixed it in the python branch but never backported that to master. The fix is to change the default value of message_content and then update everything that calls send_message() to only pass the correct contents.

Eg, defaults["message_content"] = "{context}: [{nick}] {message}" would more or less maintain the existing behavior while OnChanMsg() could skip building msg and just pass the message unaltered to send_message().

[dgw]

That's precisely the kind of response I needed to start prodding the code, thanks! As discussed on IRC, I can't use the Python branch because it lacks proper support for multiple users, so I had no way of knowing this was already fixed there.

I'll make some changes and test on my instance, so a PR is unlikely to be ready for at least a few days. (I almost never patch and PR immediately unless it's something truly trivial like a typo fix.)