pty/run on a fresh terminal waits for the shell's first prompt instead of answering busy

A new terminal's shell takes tens of milliseconds to draw its first
prompt, and a run written meanwhile answered busy, so a script's first
command was lost, while pty/status said busy 0. A line written before the
first prompt now waits for it and is sent then (a respawn in between
keeps it waiting for the new shell), and pty/status's third field says
what a run would be told: busy while a command runs or text is typed at
the prompt, not before the first prompt.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

1 files changed, 6 insertions, 2 deletions

diff --git a/docs/fs.md b/docs/fs.md
index 42e4d9b8..ac4e4b27 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -337,8 +337,12 @@ are read so that the answer costs the editor a bounded amount. `exit ?` is a
 command whose end mark carried no status, which is not a success; `error out
 of memory` is an answer that could not be made. The header is always the
 whole first line. It reads
-`busy` at once when a command is running, text is typed at the prompt or the
-shell has not drawn its first prompt; `error not run` when the shell refused
+`busy` at once when a command is running or text is typed at the prompt,
+which is also when the third field of `pty/status` reads 1. A line written
+before a new terminal's shell has drawn its first prompt is not busy: it
+waits for that prompt (a respawn meanwhile keeps it waiting for the new
+shell's) and is sent then, so the first command a script gives a fresh
+terminal is not lost; `error not run` when the shell refused
 the line without running it (a fish syntax error; the line is taken back off
 the prompt); `error shell gone` when the pane closed or its shell was
 replaced; `error no prompt marks` for a shell pardes could not instrument.