If `n` is the number of `substr` replace operations, the old
implementation did `n+1` allocations and always first copied start,
then replacement, then the remaining (unsearched) part of the original
string.
Now calculate the number of occurences of `substr` before allocating the
resulting string.
Change the algorithm to parse through the original string and only
copy the parts that must be kept into the resulting string plus the
replacements where they belong at.
Now we also only have to go through the original string twice plus we only
do a single allocation.
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
Previously we printed a format string into a `GString` to then print that
result again into a `GString` and display that.
This patch removes one level of `GString` printing by forwarding the
`va_arg` to the newly added API `win_println_va()`.
Introducing `static win_println_va_internal()` also allowed refactoring
most of the `win_print*()` and `win_append*()` implementations and removing
all the redundant code.
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
When we are not connected and run `/plugins install` we crash because we
get the account struct to check for the (xmpp) tls setting.
To apply that to the http (etc) connection to download the plugin from a
server.
This got introduced in 3a86b8c29 to fix#1624.
There are several ways to handle this (some described in 1880) in this
patch I took the route that it will use secure connection when we are
nto connected and will only check the tls.trust account setting if we
are connected.
Fix https://github.com/profanity-im/profanity/issues/1880
Thanks to @alarixnia fot the patch and bugreport.
```
Forwarding a bug reported using the NetBSD bug tracker ("Profanity crashes at login"): http://gnats.netbsd.org/57050
The code in question here handles messages by people not in the user's contact list, and what is probably happening is that the XMPP server is sending such a message before profanity has set up its window layout.
Setting roster.unsubscribed=false indeed makes profanity start without crashing, and the attached patch bails out early in the problematic code path if layout->subwin is NULL (Adrian verified for me that either of the two makes profanity work for him again). But I am not familiar enough with the profanity code to say if this has any issues.
Profanity compiled with ncurses doesn't crash because ncurses's wattron() has a guard against the user passing null pointers, but the X/Open curses library standard doesn't have this guarantee and there's no guard in the NetBSD curses implementation.
```
Fix https://github.com/profanity-im/profanity/issues/1769
