This naming is a bit hairy. I chose CTextMessage because this type of
message carries a text argument. Alternatively, it could be also called
CPrivateMessage, because the IRC protocol calls it PRIVMSG. On the other
hand, ZNC module hooks use the "Priv" naming convention for private
messages. It would look a bit weird to have OnChanMsg(CPrivMessage)...
More details and reasoning of the merge in the previous commit message.
OnUserAction(), OnUserCTCP(), and OnUserNotice() don't separate private
private and channel messages. A module could even redirect a message by
modifying its target, so technically, if they were two distinct types,
the type of a message could change on the way.
The original reason for the separation was that at some point during
CMessage development, GetChan() didn't exist in CPrivXxx, but only in
CChanXxx message types. To achieve cleaner implementation, the getter
was later promoted to CMessage and made return nullptr for non-channel
specific messages. From this point of view, the separation is also no
longer necessary since the CPrivXxx and CChanXxx types are API-wise
identical with each other.
The trick is to set the value to "-" in controlpanel. Notice that
controlpanel supports wildcards, so this can be used to easily
reset all channels back to defaults if desired.
This change alone doesn’t notify any capabilities to clients, but makes
ZNC itself offer cap-notify and builds the foundations for various
notifiable capabilities, such as away-notify, can be easily added.
This fixes the problem that CModule::GetType() returned a random
uninitialized value in CModule constructor, which was als the reason
for #905. CModule constructor signature has been changed so that it
optionally takes the type so it can be initialized appropriately.
The new type argument has a default value in order to retain source
compatibility in case some 3rdparty module would call CModule ctor
by hand instead of using the MODCONSTRUCTOR macro.
