bug(tui): clicking a path:line in tool output spawns $EDITOR detached, with the TUI still owning the terminal

[Hmbown]

Split out of #6165, which fixed the /hooks edit half and explicitly flagged this one as "Related path with the same defect". Filing it so closing #6165 does not bury it.

What happens

try_open_file_at_line (crates/tui/src/tui/history.rs:2937, reached from a mouse click on a path:line in tool output via crates/tui/src/tui/mouse_ui.rs:1680) runs:

Command::new(&editor)
    .arg(format!("+{line_num}"))
    .arg(&abs_path)
    .spawn()

spawn(), not status(). The child inherits the tty and is never waited on. The TUI does not suspend anything — not raw mode, not the alternate screen, not mouse capture, not the input pump — and goes right on rendering. Its fallback editor is vim, so the default configuration is the broken one, same as #6165.

Why #6165's fix does not cover it

#6165 moved the input-pump pause inside external_editor::with_suspended_tui, so every caller of that function is now correct by construction. This path does not call it. It does not call anything in external_editor at all — it builds its own Command and its own $VISUAL/$EDITOR/vim resolution, duplicating resolve_editor().

Why it needs a different shape, not just a pause

A pause has to end somewhere, and there is nothing here to end it: the function returns as soon as the child is spawned, so there is no point at which the TUI knows the editor exited. The loop can also spawn several editors, one per matching line in the clicked text. Whatever lands has to decide between:

• suspend and wait, one editor at a time, through with_suspended_tui (and reuse resolve_editor), or
• keep it fire-and-forget but refuse for terminal editors, i.e. only launch when the resolved editor detaches from the tty (code, subl, a GUI $VISUAL), and say so when it does not.

The second is probably what a click wants — a click should not swallow the session — but it is a product decision, not a mechanical one.

Also worth deciding in the same slice: spawning N editors from one click is unlikely to be intended.

Not verified on a live terminal

Read from source while fixing #6165; I did not reproduce it against a real tty. The reporter of #6165 reproduced the sibling defect on a PTY, and this path is strictly worse (it suspends nothing at all rather than suspending crossterm state only), so the failure should be at least as bad.

Related: #6165 (fixed), and its "companion defect" note about SIGTSTP/SIGTTIN — all three are the same missing invariant: terminal ownership is decided per call site.

[Hmbown]

Fixed in 36c6436 (PR #6271). Verified against current main rather than
taken from the commit message.

The detached spawn is gone. rg 'process::Command|\.spawn\(\)' over
crates/tui/src/tui/history.rs and history/ returns nothing — that file no
longer launches anything. What used to build its own Command is now
first_file_line_reference (history.rs:2929), which is pure: it resolves and
stats candidate paths and returns the match.

There is exactly one launch path, and it hands off the terminal. Every
production caller of run_editor_on_path / run_editor_raw outside #[cfg(test)]
is inside a with_suspended_tui closure (external_editor.rs:216 and :237),
and with_suspended_tui (external_editor.rs:246) is the sole terminal-handoff
authority. The three call sites that reach it are the click
(mouse_ui.rs:1691), /hooks edit (apply.rs:2625) and the composer
(event_loop.rs:6553). There is no second spawn path to drift.

One click now opens one editor. The old code spawned once per matching
line, so a cell with several path:line references left N editors fighting the
TUI for the same tty. first_file_line_reference returns Option, not every
match — pinned by history/tests.rs:2663 and :2678.

Also removed just now: the pre-fix doc block that was still stacked above the
new one on that function. It described opening the file in $VISUAL/$EDITOR
and returning true, neither of which the function does any more — rustdoc was
rendering both paragraphs together and telling the next reader it shells out.

What was not machine-verified: the tty handoff itself. Automated tests cover
the call graph and the single-target behaviour, not raw mode, the alternate
screen, mouse capture and bracketed paste actually being restored after the
child exits. That needs a real terminal — right-click a tool-output cell
carrying a path:line, choose "Open in editor", confirm one editor at the right
line with the TUI suspended, quit, confirm the TUI comes back intact. Closing on
the code evidence; reopen if that manual pass finds otherwise.