| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
| |
First trial. Not covering all cases yet.
|
|
|
|
|
|
|
|
| |
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 8ee2cdadc88978ea26e6b6eb56f2aaa1fd5a81df
|
| |
|
|
|
|
| |
Fix https://github.com/profanity-im/profanity/issues/1264
|
|
|
|
|
|
| |
So we can use it somewhere else too.
Regards https://github.com/profanity-im/profanity/issues/1261
|
|
|
|
| |
Just pass ProfMessage.
|
| |
|
| |
|
|
|
|
| |
So far we just subscribe and get the IDs.
|
|
|
|
|
| |
We might want to use utf8proc or something to normalize utf8 strings
later?
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add resourcepart to the outgoing carbon that is logged, so we use the
correct filenames for MUC PMs.
Dont log incoming carbons of MUC PMs as a workaround to faulty server
behaviour.
See https://wiki.xmpp.org/web/Multi-Session_Nicks#Private_Messages under
'Client-side workaround behavior'.
Regards https://github.com/profanity-im/profanity/issues/1214
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
| |
Forgot to check what happens if the length is <= 10.
|
| |
|
|
|
|
| |
And move defintion to xmpp.h
|
|
|
|
| |
Regards https://github.com/profanity-im/profanity/issues/1201
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`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
|
|
|
|
|
|
| |
Carbons where not logged so far.
Fix https://github.com/profanity-im/profanity/issues/1181
|
|
|
|
|
| |
We don't need to do all the timing stuff if last activity is disabled
anyways.
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Small bug caused by 13675fb and ce5a4ed.
Fix https://github.com/profanity-im/profanity/issues/1142
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Like discussed with James.
|
|\
| |
| | |
Feature/704 ui behaviour reconnect
|
| |
| |
| |
| |
| |
| | |
After pasis review of my code he thinks it's better to safe the
timestamp per MUC so we can account for some problems that could occur
with timing.
|
| |
| |
| |
| |
| |
| | |
For #704 we don't show the room history upon reconnect.
Now we also don't show the room subject in the channel
upon re-established connection.
|
| |
| |
| |
| | |
Let's test for mucwin earlier.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
| |
Should fix https://github.com/profanity-im/profanity/issues/1120
|
|
|
|
|
| |
Duplicate code in client_events.c and server_events.c. Let's have
events/common.c and a function containing that code.
|
| |
|
|
|
|
|
| |
Remove the windows, clear tls certs, clean omemo.
Regards https://github.com/profanity-im/profanity/issues/1089
|
|\
| |
| | |
Handle presence received before roster
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Presence of contact not found in roster are filtered out.
But sometimes roster is received after a first few presences.
We choose to store presences until we receive roster and then process
this presences.
Fixes #1050
|
|/
|
|
| |
This should close #1052
|
| |
|
|
|
|
| |
Add sv_ev_connection_features_received for that purpose
|