fix(ui): stop status bar / chat bleed-through over the external editor #131
@@ -325,6 +325,10 @@ inp_get_line(void)
|
||||
while (!line) {
|
||||
line = inp_readline();
|
||||
ui_update();
|
||||
|
jabber.developer marked this conversation as resolved
Outdated
|
||||
// Let GLib sources (notably the editor child watch) dispatch so
|
||||
// ui_resume can run if the prompt was raised mid-editor-session.
|
||||
while (g_main_context_iteration(NULL, FALSE))
|
||||
;
|
||||
}
|
||||
status_bar_clear_prompt();
|
||||
return line;
|
||||
@@ -356,6 +360,10 @@ inp_get_password(void)
|
||||
while (!password) {
|
||||
password = inp_readline();
|
||||
ui_update();
|
||||
// Let GLib sources (notably the editor child watch) dispatch so
|
||||
// ui_resume can run if the prompt was raised mid-editor-session.
|
||||
while (g_main_context_iteration(NULL, FALSE))
|
||||
;
|
||||
}
|
||||
get_password = FALSE;
|
||||
status_bar_clear_prompt();
|
||||
|
||||
Reference in New Issue
Block a user
is it safe from infinite looping?
Yes. The inner g_main_context_iteration(NULL, FALSE) is non-blocking — returns FALSE as soon as no source is ready — and the only sources we have (g_child_watch for the editor, tray timer) dispatch once per state change, not re-arm in place. The outer while (!line) is the standard blocking-prompt pattern: it exits when readline accumulates a full line (user Enter). That same loop existed before; the only change is adding the GLib iteration so a prompt raised mid-editor-session can dispatch _editor_exit_cb instead of deadlocking until the editor exits. No new infinite-loop class.