Simple `ui_resize` is sufficient for rerendering all the elements.
Other calls create complexity, slow down the applications and even introduce mem leaks.
`ui_resize` technique is already used widely, including `cmd_editor` case.
Fixes#4
Instead of always returning a `strdup()`'ed version, maybe return NULL and
handle this in the calling code.
This is still not true for `plugins_pre_chat_message_display()`, where we
return the passed `messag` in case there are no plugins, since this would
require a bigger refactor of more parts.
This also
* merges the implementation of `sv_ev_incoming_private_message()` and
`sv_ev_delayed_private_message()`, since they differed only by a single
line.
* untangles the `#ifdef` mess in `cl_ev_send_muc_msg_corrected()`.
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
In the documentation of the `muc_nick` function we can read:
> The nickname is owned by the chat room and should not be modified or freed
We should reflect that in the return type and `strdup` the value for the
plugin API.
Fixes: https://github.com/profanity-im/profanity/issues/2013
Feature discovery was marked as finished once we received a reply to the
initial request. The discovery mechanism allows to delegate the real
feature discovery to another service running on different domain and those
requests are created dynamically.
This was another instance causing the warning message described in #1940Fixes#1940 (once more)
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
Use a singleton `Jid` inside the connection instead of always re-creating
a `Jid` from the same string.
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
There were multiple reports where after a reconnect the window of the
MUC that was last opened, was empty.
`muc_join()` creates an instance of a MUC, `presence_join_room()` works
with this instance. Therefore the instance has to exist before working on
it.
I'm not sure if this really fixes the issue, but at least it didn't
happen anymore after I applied this modification.
I can't remember how I stumbled over this, either while looking at debug
logs or while looking at Valgrind output while a reconnect happened, but
something went wrong. Then I came to the conclusion that this may fix
the issue and for now it did ... maybe it comes back, then my RCA was
wrong.
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
Sometimes after a reconnect the current window would get cleared. This
was a deliberate change to fix the profanity window looking all garbled
up after providing the passphrase for a gpg key using pinentry-curses.
Fixes https://github.com/profanity-im/profanity/issues/1556
I think this PR already solves and improves the MAM situation a lot.
What's @MarcoPolo-PasTonMolo still wanted to do in this branch is:
* MAM for mucs
* Check if url and quotes autocompletion works fine
* Check if the api still works fine
* Resolve conflicts
Conflicts are solved with this commit.
MAM for mucs can be another feature PR.
The rest we can check while being on master. And more people can help
testing.
Only nicknames, photos, birthdays, addresses, telephone numbers, emails,
JIDs, titles, roles, notes, and URLs are supported
Due to the synopsis array not having enough space, `/vcard photo
open-self` and `/vcard photo save-self` are not documented properly in
the synopsis section of the `/vcard` command, but they are documented in
the arguments section
Fixed memory leak in vcard autocomplete (thanks to debXwoody)
The profanity-internal mechanism to allow connecting to a server isn't
easily portable to cURL. Therefor introduce a profanity-specific CAfile
which is managed individually and will be configured in libcurl calls.
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
- Added JABBER_RAW_CONNECT[ING/ED] connection states
- Added cl_ev_connect_raw and session_connect_raw to conform to normal
connection functions
- Fixed SIGABRT during registration
- Added a check in cmd_register to ensure it's actually connected before
registering--but this will always fail atm
Currently, only `chat_log_omemo_msg_out` can fail (i.e. return `NULL`
instead of a stanza id). In this case, the message is neither printed to
the chat window nor added to the log (since it wasn't sent).
