| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
| |
Reduce the request during startup of profanity
Removed omemo_start_sessions from sv_ev_roster_received
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 dd566d8d561099bbfc81b2fab22318bbad0cf3da.
|
| |
|
|
|
|
| |
Regards https://github.com/profanity-im/profanity/pull/1446
|
|
|
|
|
|
| |
Doesn't make sense to log if plain is not set in all cases.
Regards https://github.com/profanity-im/profanity/issues/1439
|
| |
|
| |
|
|
|
|
|
|
| |
This reverts commit 9b55f2dec0ea27a9ce4856e303425e12f866cea2.
Sorting the includes creates some problems.
|
|
|
|
| |
Regards https://github.com/profanity-im/profanity/issues/1396
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
It just does a free.
Related to b580b9ef119045f142fa4baa9689a1c5ce8864ef
|
|
|
|
|
| |
Fix for some build cases introduced in 2c94ee5a88f64332a3f41f41a4d314fc52200e31
Fix https://github.com/profanity-im/profanity/issues/1376
|
|
|
|
|
|
|
|
|
| |
Basic implementation of XEP-0373: OpenPGP for XMPP.
https://xmpp.org/extensions/xep-0373.html
Command /ox
Issue: #1331
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
973a05d15a9843f2e8f6dff598f2161367885994 to fix
https://github.com/profanity-im/profanity/issues/1050
|
|\
| |
| | |
Bugfix: Status with PGP shows offline in titlebar
|
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| | |
Regards https://github.com/profanity-im/profanity/issues/1342
|
| |
| |
| |
| | |
Instead of connection_get_fulljid() and then creating a Jid from it.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
```
cat ~/.local/share/profanity/bookmark_ignore
[jubalh@iodoru.org]
profanity@rooms.dismail.de=true
[testuser@domain.org]
testr@rooms.domain.org=true
```
Regards https://github.com/profanity-im/profanity/issues/1115
|
|/
|
|
|
|
|
|
|
|
| |
```
~/.local/share/profanity % cat bookmark_ignore
[ignore]
profanity@rooms.dismail.de=
```
Regards https://github.com/profanity-im/profanity/issues/1115
|
|
|
|
|
|
|
| |
So far we only had the logging in sv_ev_incoming_carbon() not
sv_ev_outgoing_carbon().
Regards https://github.com/profanity-im/profanity/issues/1342
|
|
|
|
|
|
|
|
| |
`/bookmark add|update` got `name` field.
By default localpart of JID is used (like before) but now we can set the
name ourselves.
Regards https://github.com/profanity-im/profanity/issues/697
|
| |
|
|
|
|
|
| |
Is usefult in many cases if we want cleaner code.
Hope this edit didn't break anything though ;-)
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
The mucuser boolean is not now needed anymore.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
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.
|