So far receipts are only send if we have enabled it and the other client
supports it.
But it could be that the other person is connected with several clients.
One supporting it and the other which doesn't. If the not supporting one
is active and we send to a fulljid, then we won't get receipts.
Probably it's best to just always send them if they are enabled in
Profanity. And not try to find out the capabilities of the other client.
Fix https://github.com/profanity-im/profanity/issues/1268
So far the correction is sent. But the UI in Profanity itself is not
updated.
Also autocompletion for `/correct` with the last sent message is
missing.
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.
If re-establish a connection don't print the room history again.
In case there there happened nothing at all since we got the room
history on the last connection.
And in case there were no new messages during the time we have been
disconnected.
Instead of printing the room history again we now print 'Re-established
Connection'.
This adds a bit of overhead since we save the timestamp upon every MUC
message.
See: https://github.com/profanity-im/profanity/issues/704
If Profanity is disconnected in any way before ping response is
received, the autoping timer will expire after the next connection
is established. As result, user will be disconnected immediately.
Cancel autoping timer in ev_disconnect_cleanup(), so it is done
for all kind of disconnections.
