On failure the error window showed a generic message with the whole log
buried in an expander. Lead instead with a focused summary: which step
failed (the process label), its command, and the last stderr lines, while
keeping the full log below. The runner passes the failing process to
error_window, which reads the executor's bounded stderr_data.
build_summary/_stderr_tail are static and unit-tested (tests/
test_error_summary.py): tail extraction, CR handling, blank-line skipping,
stdout fallback, long-line truncation, and Pango-markup escaping of paths/
messages containing & < ' so set_markup can't choke.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The executor drained child stdout/stderr via GLib.IOChannel watches on the
main loop, so a stalled or wedged GUI stopped draining the pipes and the
child would block on a full (~64KB) pipe forever — the cascade that froze a
batch when the editor/terminal died.
Replace the main-loop watches with per-stream background reader threads that
drain pipes with blocking reads into thread-safe buffers; a GLib timer on the
main thread consumes the buffers and does all parsing/UI (threads never touch
GObject/GTK). Now the child can never block on a pipe we own, regardless of
main-loop state. Also: stdout can go straight to a file when requested, stdin
is fed from a file in a thread, the retained end-of-job log is bounded, and
wait_end is guarded to run once.
Tests (tests/test_executor_io.py): line parsing incl. CR progress lines,
2MB output with no loss/deadlock, completion with the main loop never running
(the wedged-GUI case), cancel, stdout-to-file, and exit-code propagation.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
