The compose editor is spawned via fork+execvp and inherits profanity's
environment, including LINES/COLUMNS. Those hold the terminal size
captured when profanity started (set by readline/ncurses at init) and
are never refreshed on resize. A curses-based editor (nano, vim, ...)
honors LINES/COLUMNS over the real window, so it renders at the
launch-time dimensions and leaves the rest of the window unused after
the terminal has been resized.
Build a copy of the environment without LINES/COLUMNS before forking and
point the child's environ at it, so the editor's curses falls back to
ioctl(TIOCGWINSZ) and tracks the current window. The env is assembled in
the parent so the child only swaps the environ pointer, which is
async-signal-safe -- unlike unsetenv() -- in the multithreaded
fork->exec window. profanity itself is unaffected: it already reads the
live size via ioctl in ui_resize(), and its own environment is intact.
Guard against re-entrant editor launches, abort editor on Ctrl-Z,
and centralize suspend-aware redraws through prof_doupdate() to prevent
terminal corruption when SIGTSTP is received while editor is active.
Removes SIGUSR1 editor escape in favor of standard pkill <editor> recovery.
The synchronous `get_message_from_editor` blocked the main loop (`prof_run`) while launching an external editor like `vim`, halting network I/O in `session_process_events` and preventing incoming message reception.
Introduced `get_message_from_editor_async` for `cmd_editor` to run the editor asynchronously. It forks and execs the editor in a thread (`editor_thread`), suspending NCurses to free the terminal. The main loop skips `inp_readline` and `ui_update` via a new `background_mode` flag while the editor runs, allowing `session_process_events` to keep the connection alive.
On editor completion, `editor_process` (called per loop iteration) resumes NCurses with `ui_resize`, inserts the result into the readline buffer and clears `background_mode`.
Retained synchronous `get_message_from_editor` for ~20 existing code paths (e.g., `vcard_nickname`) to avoid breaking them.
Tested with `vim` and `nano`: confirms no rendering conflicts, messages received during editing, and seamless resume. Edge cases like editor crashes handled via error logging and seamless resume.
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>
`data_dir` would have been leaked if directory creation failed.
`editor_argv` was leaked at some point, no idea why.
```
==1244734== 118 (32 direct, 86 indirect) bytes in 1 blocks are definitely lost in loss record 6,299 of 7,824
==1244734== at 0x4846CC3: realloc (vg_replace_malloc.c:1451)
==1244734== by 0x5E85AD0: g_realloc (in /usr/lib/libglib-2.0.so.0.7600.1)
==1244734== by 0x5E4A004: ??? (in /usr/lib/libglib-2.0.so.0.7600.1)
==1244734== by 0x5E4A7B1: g_ptr_array_add (in /usr/lib/libglib-2.0.so.0.7600.1)
==1244734== by 0x5EA4235: g_strsplit (in /usr/lib/libglib-2.0.so.0.7600.1)
==1244734== by 0x1F143C: get_message_from_editor (editor.c:92)
==1244734== by 0x193F6B: _inp_rl_send_to_editor (inputwin.c:950)
==1244734== by 0x614642F: _rl_dispatch_subseq (readline.c:916)
==1244734== by 0x6146C85: _rl_dispatch_callback (readline.c:823)
==1244734== by 0x616739F: rl_callback_read_char (callback.c:241)
==1244734== by 0x1923DB: inp_readline (inputwin.c:188)
==1244734== by 0x149860: prof_run (profanity.c:117)
==1244734== by 0x2283E8: main (main.c:186)
```
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
* Make editor executable into a string to be able to support
(multiple) flags.
* Change /help executable to suit this new feature
Signed-off-by: Daniel Santos <dacs.git@brilhante.top>
* use GLib functions to write&read compose file
* trim trailing new-line characters from compose file
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
In case we're not connected yet and press Alt+c a segfault occurred
since `conn.xmpp_conn` is dereferenced while it's still `NULL`.
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
