We now dont get the log files from the text files via chat_log_get_previous() anymore.
We use the sql backend via log_database_get_previous_chat().
So far it just has the same behaviour like chat_log_get_previous(),
except that in _chatwin_history() we don't pass the sender to
win_print_history() which should be fixed in a commit soon.
And log_database_get_previous_chat() can later easily be expanded to fix
https://github.com/profanity-im/profanity/issues/205.
Maybe if we only use `/connect` we dont have ProfAccount. In that case
we won't log anything. Only if a account is used we log.
If this is the case or the init of the db didn't work we still want
profanity to run but wont log anything to the db.
Timestamps are only set if a message is delayed.
If none is set let's set it upon recaival so we don't have to set it
when it gets displayed.
This means we will also have it for logs etc in the ProfMessage.
I plan to save all messages in an SQLite db.
For retrieving information it's nicer than having it in a text file.
We will have more info in there and easier to parse it.
This will also be good for later MAM
(https://github.com/profanity-im/profanity/issues/660).
Regular text files will still be an option for users so that they can
easily grep them and do whatever they like.
Internally Profanity will only use the SQLite db.
xmpp_stanza_add_child() takes own reference to the child stanza.
Therefore we have to release our reference or the child is lost
and not freed otherwise.
The memory leak happens when a presence is received for a MUC room. The
JID is not present in the roster, so updating its status is ignored. We
have to free resource in this case, because it has no owner and is lost
otherwise.
==25736== 47 (32 direct, 15 indirect) bytes in 1 blocks are definitely lost in loss record 1,625 of 3,399
==25736== at 0x4A330FF: malloc (vg_replace_malloc.c:309)
==25736== by 0x13A962: resource_new (resource.c:47)
==25736== by 0x145501: _available_handler (presence.c:665)
==25736== by 0x145501: _presence_handler (presence.c:399)
==25736== by 0x145501: _presence_handler (presence.c:358)
==25736== by 0x80D5F34: handler_fire_stanza (in /usr/lib64/libstrophe.so.0.0.0)
==25736== by 0x80D2B49: _handle_stream_stanza (in /usr/lib64/libstrophe.so.0.0.0)
==25736== by 0x80E15CE: _end_element (in /usr/lib64/libstrophe.so.0.0.0)
==25736== by 0x843EE9B: doContent (in /usr/lib64/libexpat.so.1.6.10)
==25736== by 0x843F94B: contentProcessor (in /usr/lib64/libexpat.so.1.6.10)
==25736== by 0x8441E77: XML_ParseBuffer (in /usr/lib64/libexpat.so.1.6.10)
==25736== by 0x80D586B: xmpp_run_once (in /usr/lib64/libstrophe.so.0.0.0)
==25736== by 0x13E07E: connection_check_events (connection.c:119)
==25736== by 0x13869C: prof_run (profanity.c:129)
Fixes#1279.
Some users might want there nick to always stay white (etc) for easier
recognition.
Now we can do `/color own off` to not generate the color based on
xep-0392. The `me=` color (etc) from the theme will then be used.
Once we run this command `theme_load()` is called again.
And the theme looks totally wrong.
We encountered this at other times already and I think it's nothing
wrong with this new code here now but that there seems to be a missing
closing attr for the color when drawing.
Should be investigated seperately.
Fix https://github.com/profanity-im/profanity/issues/1288
Most clients have them enabled by default already for a smoother modern XMPP experience.
Enable by default: allowing message corrections, sending of read
receipts, enabling carbons, typing/chat states.
If users input strange stuff and we can't create a jid from it even the
setting is set to 'user' we still should fallback to the regular
identifer.
For example with `/msg @name%matrix.domain.org@matrix.org hi`.
win_println_incoming_muc_msg() always used the current time. Now let's
use whatever is sent int he message struct (from the delay stanza or
the current time that we set now once the message is received).
No playing with the time upon display anymore.
I suspect this was just a copy paste error.
`_win_create_simple_layout()` is called in other creation functions like
`win_create_config()` or `win_create_private()`.
I suspect when `win_create_muc()` was created it was just copied. But in
this function we actually set the layout ourself later.
So calling the function isn't needed.
Regards https://github.com/profanity-im/profanity/issues/1279
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
`/logging group color` has:
* `unanimous` which will color it with one unanimous color. Like it was
done always.
* `regular` which colors it like regular incoming messages.
Regards https://github.com/profanity-im/profanity/issues/1261
* Add .builds/openbsd.yml for builds.sr.ht
* Update travis-build.sh -> ci-build.sh with OpenBSD case
* Fix libdl check in configure.ac (OpenBSD has libdl built-in)
* Fix some minor issues found when compiling on OpenBSD with GCC (e.g.
uninitialized variables)
If we are connected with another client and send a message, then correct
it. We now display it correctly in Profanity.
Id wasn't saved for carbon copied messages too so far.
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
In aa3693daa211b36c78d136d5a1ee9f3258e21352 I renamed
`win_println_me_message()` -> `win_print_outgoing_muc_msg()`.
Now: `win_println_them_message()` -> `win_println_incoming_muc_msg()`
to be more consistent and descriptive.
XEP-0308 Version 1.1.0 (2019-05-15) states "It is expected that clients will not send message corrections to clients that do not support them, as non-supporting clients will render these as duplicate (corrected) messages"
```
10:12:47 - jubalh: Do clients actually check whether other clients support xep0308 (LMC) before sending?
10:13:13 - pep.: not poezio, and I doubt anybody does. it's the "but carbons/MAM" argument
10:13:49 - jubalh: Profanity doesnt support this yet. So I always get the message twice. One time the message, and then the corrected ones. And I think that's right. But I understood xep0308 correctly it sais a
client shouldnt sent a message with 'replace' if the client doesnt support it? I don't see why
10:14:50 - Ge0rG: jubalh: because you might also use Conversations and read the backlog from MAM on conversations
10:15:51 - jubalh: Ge0rG: sorry?
10:16:36 - Ge0rG: jubalh: when I'm sending you a message, I don't know which client you'll use to read it. So it doesn't make sense to limit the features I use
10:27:57 - jubalh: Yes. That's why I'm confused by thestatement in the XEP
10:28:13 - jubalh: "It is expected that clients will not send message corrections to clients that do not support them, as non-supporting clients will render these as duplicate (corrected) messages. "
10:28:37 - Holger: Yes, you're both saying the same thing. And yes I agree, that part of the XEP is nonsense. We have that "check whether the peer's client supports it" stuff in various XEPs that depend on
recipient's features and it never makes sense as it doesn't cope with multi-device, MAM, groupchat.
10:28:53 - jubalh: First: You don't know if he is connected with several clients. Some supporting it and some not. Second: Why not just resend the new corrected message? Then he has both messages and no
information is lost. If he only gets the first one information is lost
10:29:20 - jubalh: Okay
10:29:30 - jubalh: Then I won't implement it this way. Thanks guys!
10:29:34 - Holger: Well UX is a bit meh if the recipient doesn't support it (I'm an MCabber user and know what I'm talking about) but I see no better solution, yes.
```
So it makes more sense to just always send it. Non supporting clients will then get the message and the corrected message. So they get it "twice". Which is the right thing to do in my opinion.
_win_print() and _win_printf() sound like they are the same. But
actually they are something totally different.
I renamed _win_print() to _win_print_internal() for that reason. It's
more about actually drawing to the ncurses window.
_win_printf() calls _win_print() and also writes the text to the window
buffer. Which _win_print() didn't, it was really just the ncurses
specific things.
In some cases there is _win_print_internal() called after a
buffer_append() in those cases it might be more correct to actually call
_win_printf().
It was not done so far. But probably is better. But will mean a bit more
operations.
I'll have to check this later.
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.
I think both the window and the buffer should also be cleared in case
`/clear` is issue and persist_history is off.
Otherwise it could happen that win_redraw() redraws the whole content of
the buffer again.
So far we saved the timestamp which also had the `from`.
But we need this only to find out whether it's MUC history.
For displaying we should use the oldest delay timestamp.
Also in
61f66966dd (diff-4926fd4577a336bd3eb240f8104a5c5bL837)
a error was introduced.
Before we saved the timestamp in all cases. And only if timestamp AND
from was given we went into MUC history case.
Normal timestamp saving was not done anymore only if it also had a from
attribute.
Regards https://github.com/profanity-im/profanity/issues/1254
So far we got the first delay with a from that comes from the server.
This way we know it's MUC history.
Now we take the first time stamp we actually find. Which is likely the
one being added first. And should contain the correct time to display.
It would be nicer to actually compare the dates though.
Regards https://github.com/profanity-im/profanity/issues/1254
Cannot be configured for now.
Can be set via `adv.notify.discoversion` in the `notification` section.
Will notify about version requests via XEP-0092 and XEP-0232.
Client version can still be seen via caps (capabilities).
See `stanza_attach_caps()`.
`/roster room use name` to use the name of the MUC in the roster list.
`/roster room use jid` to use the jid of the MUC in the roster list.
Display it only in case `/roster room by none` is set so far.
prekey is defined as `<xs:attribute name="prekey" type="xs:boolean"/>`
which allows both `true` and `1` as truthy values.
Not checking for `1` breaks omemo encryption when interacting with
clients which set prekey="1", example: psi+ 1.4.983
Regards https://github.com/profanity-im/profanity/issues/1247
So far `/occupants char *`, `/roster contact char *`, `/roster room char #`,
`/roster header char -`, `/occupants header char -` was saved and
loaded from the preferences.
But was overwritten when the theme was loaded. If the theme didn't set
these values the value was just cleared. Despite that it might have been
set in the users preferences.
Funny enough the themes don't operate generally like this.
For example `otr.char` is not cleared.
This is again due to our borked theme/prefs concept
(https://github.com/profanity-im/profanity/issues/1077).
For now let's just use the one set from the preferences if it's set. The
theme will however overwrite it if it is set there.
Fix https://github.com/profanity-im/profanity/issues/1244
So far we removed the avatar feature only after a succesful retrive in
avatar_request_item_by_id() before we are going to retrieve the actual
image.
We should remove it at every `/avatar barejid` call too so in case one
retrieval was unsucessful that we can call it again.
So far it seems like there is no other way to trigger getting the nodes
except announcing that we support the avatar feature.
So far we printed one after the last received message, which doesn't
make much sense of course.
Now only print one if there is not already one present.
This is because the actual command that parses itself (cmd_logging) returns false if it didn't get the expected parameters.
Handing the printing however is done by another function. This function is added to the Command struct as setting_function.
So if this is set, and the actual command returns false. We should just call the setting_function and not print the error message.
Fix https://github.com/profanity-im/profanity/issues/1237
The last 3 commits added basic support.
Thanks @aaptel!
This commit adds basic settings interface to use it.
See `/color on|off`.
We still have to enable settings for color blindness.
And maybe another setting to decide whether to color the
occupantslist/roster with the same algo.
Regards https://github.com/profanity-im/profanity/issues/1191
* add theme_hash_attrs()
* when printing a user message check PREF_COLOR_NICK to decide whether
to colorize it or not
ideally we should hash the jid instead of the nick but this is already
a first step.
* add the HSL values of each of the 256 terminal colors
* add color_pair_cache_hash_str()
* move common code to _color_pair_cache_get() helper func
after hashing a string to a color, return the closest matching
terminal color using euclidian distance of the HSL diff vector (this
method was found empirically and seems to work well enough...)
From @xaizek s comment on issue #1235:
```
If the move would cause the window to be off the screen, it is an error and the window
is not moved.
Resize on the other hand doesn't fail like this according to its documentation. So new size needs to be applied first.
```
Big thanks to @xaizek for taking a look at our code and helping us!!
Regards https://github.com/profanity-im/profanity/issues/1235
This is encountered when biboumi is used.
Example: `/join #debian-next%irc.oftc.net@biboumi.lebihan.pl`
It seems then time can be null.
g_date_time_format() will not work in this case although time_pref will
not be "off". So let's not call g_date_time_format() in this case. But
treat it like time is set to off.
However message reflection will not work properly with biboumi.
Probably we dont get origin-id.
Fix https://github.com/profanity-im/profanity/issues/1230
https://github.com/profanity-im/profanity/issues/1190 had another issue:
Sometimes servers send multiple </delay> and we just checked the first
one we got and only used it if the 'from' attribute was fitting.
However it could be that we actually wanted the second </delay> element
and there the 'from' would have been right.
So we need to loop through them until we get the one with the fitting
'from'.
Fix https://github.com/profanity-im/profanity/issues/1190
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
The problem is that in _handle_groupchat() we look for
STANZA_NS_STABLE_ID which will result in origin-id or stanza-id.
It seems like prosody servers send origin-id first, so this worked in
all my tests. But actually we cannot be sure of the order.
So far we stopped after the first element was found.
I only found xmpp_stanza_get_child_by_ns() and
xmpp_stanza_get_child_by_name() in libstrophe. But we need a combination
of both.
So I created stanza_get_child_by_name_and_ns() for Profanity. I need to
remember to upstream this to libstrophe later (if they really don't have
such a function).
Fix https://github.com/profanity-im/profanity/issues/1223
Before we had `/online`, `/away`, `/dnd`, `/chat`, `/xa`.
These commands are no longer available.
We have `/status set online` etc now.
Before `/status` was used to get the status of a contact.
This now moved to `/status get`.
Regards https://github.com/profanity-im/profanity/issues/1116
`/invite <contact>` became `/invite send <contact>.
`/invites` became `/invite list`.
`/decline` became `/invite decline`.
Accept is still done via `/join`.
Regards https://github.com/profanity-im/profanity/issues/1116
Additionally to `/resource titlebar on` we now allow the setting via
/titlebar show|hide resource` since it's about the titlebar.
But makes sense to have it in `/resource` too because there is
`/resource message on|off` too. And this one doesnt have an setting of
it's own.
Regards https://github.com/profanity-im/profanity/issues/1116
Regards https://github.com/profanity-im/profanity/issues/200
This doesn't work yet. And I have no idea why.
Weird behaviour:
- start profanity
- type 'ASDF'
- ctrl+arrow down
-> text vanishes (like intended)
- arrow up
-> nothing happens (intended is that the last history item [ASDF]
appears)
- type 'ABC'
- press enter
- arrow up
-> ABC appears
- enter
- type 'UUU'
- ctrl+arrow down
- type 'ZZZ'
- enter
- arrow up
- ZZZ appears
- arrow up
- UUU appears
So in the latter case we added to history and deleted from the input
line and then immediately entered new text and pressed enter, to add
this to the history too.
When we do this the not sent text succesfully was stored in history.
Previously we had `/tls show on|off` to manipulate the UI setting for
the title bar. To decide whether to show TLS info there or not.
This should go into `/titlebar`.
Now we have `/titlebar show|hide tls` for this.
Regards https://github.com/profanity-im/profanity/issues/1116
XEP-0184: Message Delivery Receipts, *requires* the id attribute.
Generally this is not the case.
For this reason the id was only present in the DeliveryReceipt struct
since it was only used for XEP-0184.
For https://github.com/profanity-im/profanity/issues/660 XEP-0313 MAM
and https://github.com/profanity-im/profanity/issues/805 XEP-0308 Last Message Correction
we will also need the id.
So in preparation for further work let's move the id to the general
ProfBuffEntry.
We will need to adapt code so that we actually always write the ID if we
receive one.
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.
For OMEMO we had a list with our sent messages.
It was used so that we don't decrypt our own messages in MUCs that come
in via reflection.
Recently for https://github.com/profanity-im/profanity/pull/1209 we
started to use origin-id and use an algorithm so we can detect our own
sent messages via checking origin-id.
Profanity uses the same id for the message ID and origin-id.
With 06f300a42c we added the
message_is_sent_by_us() function.
We implemented XEP-0359 this way to fix
https://github.com/profanity-im/profanity/issues/1201 so that we don't
log our own messages in MUCs twice.
We can now check whether the message was sent by us using this function
and can get rid of the list.
Probably we could also put many parts of the sv_ev_room_message()
function inside (else) part of `if (!(g_strcmp0(mynick,
message->jid->resourcepart) == 0 && message_is_sent_by_us(message))) {`.
Have to look more closely whether any of this needs to be run in case
the message actually comes from us.
Some clients (eg. PSI) are sending the stanzas delimited by whitespace
text nodes, which will fail while looping through the <prekeys/>
children and also print weird errors when iterating through the <list/>
of devices.
When debugging this, I was looking at the XML of Gajim and PSI and first
was somehow confused why Profanity printed "OMEMO: received device
without ID" while the XML looked identical (minus the actual IDs and the
JIDs of course).
However, Gajim was sending the XML without whitespace nodes in between
and PSI did not, so for example the following (with the relevant
whitespace nodes marked with X):
<message type="headline" to="..." from="...">
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items type="headline" node="eu.siacs.conversations.axolotl.devicelist">
<item id="...">
<list xmlns="eu.siacs.conversations.axolotl">
X <device id="..."/>
X <device id="..."/> X
</list>
</item>
</items>
</event>
<delay xmlns="urn:xmpp:delay" stamp="..." from="..."/>
</message>
... would result in three times the "OMEMO: received device without ID"
error, because we actually have three XML text nodes here that obviously
don't have an "id" attribute.
Now since the <list/> children above aren't really a problem and only
annoying, text nodes in the <prekeys/> stanza actually cause
omemo_start_device_session_handle_bundle to return failure.
I've fixed this by explicitly matching the stanza names we are
interested in, skipping everything else.
Signed-off-by: aszlig <aszlig@nix.build>
Reported-by: @devhell
For now we initialize gtk in tray_init().
Should maybe use a general function and check in tray_init and
clipboard_init whether gtk was already initialized.
Also we initialize mucuser properly.
Now in case of a carbon of a MUC PM we sv_ev_incoming_carbon() which
calls _sv_ev_incoming_plain() and then we log it via chat_log_msg_in()
in there.
But we also get the sv_ev_incoming_private_message() and call
chat_log_msg_in() in there too. So the incoming message get's logged
twice.
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
Change default themes text color
Using "default" instead of white makes the default better readable
when using a black/dark font on white/light background.
May fix#535
So far if one had enabled `/history` and did `/msg somenick` the history
was loaded from file and displayed like this:
```
04-04-17 15:23 - 3/4/2017:
01-01-00 10:30 - me: ....
01-01-00 10:31 - somebody: ....
01-01-00 10:32 - somebody: ....
```
So the first line contained the actual date. But the date used in each
line was always 01-01-2000. This date was for some reason hardcoded.
This commit now actually uses that date to build the proper GDateTime
instead of just printing it.
Fix https://github.com/profanity-im/profanity/issues/922
This caused the bug mentioned in the PR comment:
```
It seems with the changes done here we get a crash in: src/xmpp/message.c message_handlers_init() when looking up handlers: ProfMessageHandler *handler = g_hash_table_lookup(pubsub_event_handlers, curr->data);.
Steps to reproduce:
open Profanity and connect
/autoping set 10
/autoping timeout 10
stop WiFi/connection
wait for Lost connection
restart wifi
/connect
```
So far only with dummy value.
We will need an identifier that we can hash together with a message ID
and put in as the origin-id.
So when we receive message we can unsplit it and see if it was sent from
this client.
Regards https://github.com/profanity-im/profanity/issues/1207
ncursesw defines _XOPEN_SOURCE macro via command-line. In particular, it
is defined in ncursesw.pc and extracted via pkg-config. From other side,
Python defines the same macro unconditionally in pyconfig.h. Python-3.x
defines the macro with value different than ncursesw does. In turn, this
causes a warning that the macro is redefined. And warnings are treated
as errors.
Since both entities define the mecro unconditionally, we can't simply
reorder headers as Python developers suggest. So, undefine the macro
just before the <Python.h> to fix this silly issue.
room is either argv[0] or allocated by GString. We have to free memory
in the 2nd case. Replace argv[0] with g_strdup(argv[0]) in order to
make unconditional g_free().
If we get a private message from a user in a MUC profanity shows this
like:
`profanity@roomsASDF.dismail.de/Martin: Hi`
This was so far logged at:
`~/.local/share/profanity/chatlogs/my-account-at-server/profanity_at_rooms.dismail.de/2019_09_04.log` as:
```
10:48:13 - profanity@rooms.dismail.de: Hi
```
So the nickname was not saved anywhere. This is due to us not knowing
whether we got a regular message from user@server.org/resource or a MUC
PM from room@server.org/user.
We now check for `<x xmlns='http://jabber.org/protocol/muc#user' />` and
add the resourcepart to the logging if we get it.
The file will be created at
`~/.local/share/profanity/chatlogs/my-account-at-server/profanity_at_rooms.dismail.de_nick` and look like:
```
23:59:43 - nick: Hi
```
Fix https://github.com/profanity-im/profanity/issues/1184
`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
We didn't set the variables to NULL, but the rest of the code depends on
this check.
```
==22201== Invalid read of size 8
==22201== at 0x44E560: autocomplete_clear (autocomplete.c:69)
==22201== by 0x427B2C: muc_invites_clear (muc.c:190)
==22201== by 0x461328: ev_disconnect_cleanup (common.c:59)
==22201== by 0x463FB5: cl_ev_disconnect (client_events.c:91)
==22201== by 0x431252: cmd_disconnect (cmd_funcs.c:1234)
==22201== by 0x47E883: clears_chat_sessions
(test_cmd_disconnect.c:28)
==22201== by 0x487E9E1: _run_test (in /usr/lib64/libcmocka.so.0.7.0)
==22201== by 0x487ECCC: _run_tests (in /usr/lib64/libcmocka.so.0.7.0)
==22201== by 0x47F1BE: main (unittests.c:629)
==22201== Address 0x814b690 is 0 bytes inside a block of size 24 free'd
==22201== at 0x48379AB: free (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==22201== by 0x44E5F7: autocomplete_free (autocomplete.c:90)
==22201== by 0x4278A0: muc_close (muc.c:97)
==22201== by 0x47DBAA: cmd_join_uses_password_when_supplied
(test_cmd_join.c:169)
==22201== by 0x487E9E1: _run_test (in /usr/lib64/libcmocka.so.0.7.0)
==22201== by 0x487ECCC: _run_tests (in /usr/lib64/libcmocka.so.0.7.0)
==22201== by 0x47F1BE: main (unittests.c:629)
==22201== Block was alloc'd at
==22201== at 0x483677F: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==22201== by 0x44E51B: autocomplete_new (autocomplete.c:57)
==22201== by 0x427837: muc_init (muc.c:88)
==22201== by 0x47DA77: cmd_join_uses_password_when_supplied
(test_cmd_join.c:154)
==22201== by 0x487E9E1: _run_test (in /usr/lib64/libcmocka.so.0.7.0)
==22201== by 0x487ECCC: _run_tests (in /usr/lib64/libcmocka.so.0.7.0)
==22201== by 0x47F1BE: main (unittests.c:629)
```
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 theme color applies to the tab title text of the statusbar tab that
is currently shown.
The (somewhat confusingly named) `statusbar.active` theme color now
applies to all other tabs (before, it applied to all tabs).
Coloring of a tab that is highlighted/has new messages is done as before
using the `statusbar.new` theme color.
The default color is set to `cyan`, and thus causes no visible change
for users -- until modified.
Glib can print error messages to stderr and blocking write freezes
Profanity if the buffer is full. Move stderr to nonblocking mode
in hope that glib will skip printing on EWOULDBLOCK error. In this
case we lose some error messages, but Profanity continues working.
https://gultsch.de/dino_multiple.html mentions CVE-2019-16235, CVE-2019-16236 and CVE-2019-16237.
CVE-2019-16235: Is checking the from in carbon messages. We do that.
CVE-2019-16236: Is checking the from in roster pushes. We do that but
didn't log it yet.
CVE-2019-16237: Is checking the form in MAM messages. We don't support
them yet.
