Otherwise we print the freshly received message to the window twice.
Once when receiving (and immediately printing), then logging it, and
then again when we print the last 10 log entries.
Fix https://github.com/profanity-im/profanity/issues/1305
We use the same incoming function as for regular incoming text here. But
don't want to filter out our own messages since we didn't print them
during sending.
Follow up to 8ee2cdadc8
Gajim sends \u200E and \u200F for RTL.
It is planned that Gajim stops doing this and uses some GTK feature to
get the same result.
However users expressed the whish that we filter out such characters in
incoming messages before displaying them to make Profanity more robust.
I'm still not sure whether I like the solution because it means a lot of
allocating/deallocating upon every new message.
Fix https://github.com/profanity-im/profanity/issues/1220
Profanity sends the same value for both. Other clients might not.
Safe both since we could need them later.
Once we implement Last Message Correction we will need the regular id.
If we override it with origin-id and another client chooses to not use
the same value for id and origin-id then we can't interpret the id sent
with the LMC request correctly.
If I'm not mistaken MUC PMs have not been logged at all if there was no
other client sending carbons.
This should add MUC PM logging functionality.
We still need to make sure carbons log to the same file.
Regards https://github.com/profanity-im/profanity/issues/1214
`sv_ev_room_message()` called `groupchat_log_msg_in()` to log all
incoming MUC messages.
`cl_ev_send_muc_msg()` calls `groupchat_log_msg_out()`.
So messages sent by the user himself was logged two times.
Filter the incoming messages and only log the ones not from our occupant
jid/nick.
Fix https://github.com/profanity-im/profanity/issues/1201
Incoming carbons are logged as normal message already.
So we had this logged twice but didn't log outgoing carbons,
send from our account but by another client, at all.
Fix https://github.com/profanity-im/profanity/issues/1181
This occured with a user running Cisco Jabber. It seems this server
sends repeated presence subscribed stanzas. And although I find this
strange according to RFC this seems to be ok.
So let's filter them and only display in the console output and to the
log. But don't open seperate windows.
Fix https://github.com/profanity-im/profanity/issues/1165
Probably missing copy of body to plain in carbon and privmessage.
Only covers the incoming message path because goal is OMEMO decryption
of untrusted message.
Cover some of the log functions but not all.
