Regards https://github.com/profanity-im/profanity/issues/1488
Actually I would have loved to see the stanza that caused the segfault
since I'm not entirely sure whether this actually means that we do
something wrong earlier on.
Right now I don't know why the to_jid should be empty.
Let's prevent the segfault for now and see whether we get further
bugreports later.
Segfaulting issue got introduced with dd566d8d56.
Plain chat messages not working for non-carbon + no OTR support.
On master we did some clean-up. The problem is at https://github.com/profanity-im/profanity/blob/0.9.patch/src/event/server_events.c#L625 (0.9.0). The implementation looks like:
- HAVE_LIBOTR is set - _sv_ev_incoming_otr
- HAVE_LIBOTR is not set - _sv_ev_incoming_plain
I think the `_sv_ev_incoming_otr` can handle otr and plain, because I didn't find a `_sv_ev_incoming_plain` if `HAVE_LIBOTR` is set.
On master for 0.10.0 the implementation is much better:
https://github.com/profanity-im/profanity/blob/master/src/event/server_events.c#L623
But, we just call `_sv_ev_incoming_otr` independent of `HAVE_LIBOTR`.
Unfortunately, `_sv_ev_incoming_otr` is doing nothing if `HAVE_LIBOTR` is not set:
https://github.com/profanity-im/profanity/blob/master/src/event/server_events.c#L538
I did some more clean-up at sv_ev_incoming_message and changed the implementation of `_sv_ev_incoming_otr`.
```
static void
_sv_ev_incoming_otr(ProfChatWin *chatwin, gboolean new_win, ProfMessage *message)
{
// OTR or plain
plain
}
```
The caller do not take care of `HAVE_LIBOTR`, call `_sv_ev_incoming_plain` if you are sure it's a plain message or call `_sv_ev_incoming_otr`. `_sv_ev_incoming_otr` can be used for otr / plain or for plain only.
Fix https://github.com/profanity-im/profanity/issues/1280
p_contact_set_presence() is triggered in
(roster_process_pending_presence) to set the presence to online
after the roster is displayed.
This happened to me _every time_ with one certain account on my server.
But not even once with other accounts on my server.
I don't understand why that is the case, but AFAIK the code should be
like it is in this PR anyways.
roster_process_pending_presence() was added there in
973a05d15a to fix
https://github.com/profanity-im/profanity/issues/1050
There is code to redraw the ui, because the user may enter a passphase for the
private key. There was also a ui_init, which shouldn't be called, because it
will set the status to the initial state, which is 'offline' and 'no tls'.
Issue: #1327
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
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
