The docs say what Restore renumbers and re-runs, what Tty takes, and how a range reaches a REPL

Round 12's doc findings: the README's ctl line gains Restore, Placement and
size (still 45 lines, detail in fs.md); Tty's argument is a shell and Tty
on a pane's ctl opens a new pane; a .py pane's range goes to its REPL as
an MX<q0> <q1> event write-back; after a Restore panes are renumbered
(columns count from 1 again, so often keep theirs), a command pane shows
exit ? and does not re-run, and REPL bindings are gone. acme's p adds no
newline to what it prints (ecmd.c:744, pdisplay), so pardes's p does not
either.

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

1 files changed, 12 insertions, 3 deletions

diff --git a/docs/fs.md b/docs/fs.md
index 03851d8d..cf90aadc 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -172,7 +172,11 @@ before the answer was read; the log is the authority): dial again -- a 9ns
 mount is one such connection, so after a Restore stop it and start 9ns
 again, or every file under it fails -- and the new
 log names the restored panes and
-`restore <path>`. The answer has 200 ms to leave before the cut, so a slow
+`restore <path>`. Restored panes have new serials (`restored <old>
+<new>` maps them) and so may columns (`restoredcol`; a fresh editor counts
+column serials from 1 again, so they often come back the same). A command
+pane comes back showing what it showed, its tag `exit ?`: its command is
+not run again. REPL bindings are not dumped. The answer has 200 ms to leave before the cut, so a slow
 client may see only the cut; the log's `restore <path>` is what says the
 Restore happened. Keeping connections across it would mean carrying serials
 and opens into the new editor, which acme, whose Load only adds windows,
@@ -305,7 +309,9 @@ same tree without leaving the process.
   the browser.
 - a line written to `exec` is a middle click: a command word from
   `src/builtins.zig` (`Save`, `Del`, `New`, `Newcol`, `Mount NAME DIAL`,
-  `Unmount NAME`, `Dump`, `Restore`, `Msg TEXT`, `Find`, `Grep`, `Tty`, ...),
+  `Unmount NAME`, `Dump`, `Restore`, `Msg TEXT`, `Find`, `Grep`, `Tty`, ...;
+  `Tty`'s argument is the shell it runs, `Tty fish`, and `Tty` on a pane's
+  ctl opens a new terminal pane beside that one, not in it),
   or anything else, a command line. Written at a terminal at its prompt it
   is typed into that shell (and a terminal whose shell exits, `exit` typed
   or run, closes its pane). From anywhere else -- a file, a scratch, a tag,
@@ -375,7 +381,10 @@ and its last line is indented, a second `\r`: one Enter leaves such a block
 open; a middle click does all of this
 itself, holding the Enter until the REPL answers the paste), since line by line a blank line ends a Python block and Python
 3.14's REPL auto-indents each line typed into it. The REPL gets the text
-wherever it is -- at a `pdb` or `input()` prompt too. `Kill` does not stop
+wherever it is -- at a `pdb` or `input()` prompt too. Over 9P, a range of a
+`.py` pane goes to its bound REPL as a click would: write the event record
+`MX<q0> <q1>` back to the `.py` pane's `event` (a range past its end is
+refused, `range past end of body`). `Kill` does not stop
 what a REPL runs, since pardes did not start it; `sig INT` on the REPL
 pane's `pty/ctl` interrupts it as Ctrl-C would. Bindings are not dumped, so a Restore leaves none.