The docs: the raw paste's second Enter, event flags and write-back, a new Tty's ls

Round 14's doc findings: a raw pty/data paste of more than one line needs
the second \r unless it ends in a newline (not only an indented last
line); the event flag bits (1 builtin, 2 expansion, 4 filename, 8
chorded, with its two records) and what writing back each record kind
does; why a new Tty types ls; and the sam box's N+1 for text without a
final newline (out of range).

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

1 files changed, 14 insertions, 5 deletions

diff --git a/docs/fs.md b/docs/fs.md
index 7c13d223..1e65bd00 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -386,9 +386,8 @@ is no gesture and is never sent: a script writes to the REPL pane's
 `pty/data`, multi-line code as a bracketed paste (`\e[200~<code>\e[201~`,
 then `\r` in a write of its own once the REPL has echoed the paste --
 Python 3.13's REPL takes an Enter read with the paste as part of it, even a
-one-line one -- and, only when the pasted code does not end in a newline
-and its last line is indented, a second `\r`: one Enter leaves such a block
-open; a middle click does all of this
+one-line one -- and, for a paste of more than one line that does not end
+in a newline, a second `\r`: one Enter leaves a multi-line input at `...`; 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. Over 9P, a range of a
@@ -655,7 +654,9 @@ an open renders its frame; stat the entry.
 `/log` is one ring (64 KiB) that records whether or not anyone reads it:
 `new`, `del`, `rename` (a terminal's too, as its shell changes directory --
 a new terminal is `new N /` until its shell says where it is, then renamed;
-it runs `ls` once at its first prompt, a greeting that shows the directory --
+it runs `ls` once at its first prompt, a greeting that shows the directory
+it opened in, since a terminal is named by its directory and nothing else
+on it says where it is --
 since a terminal is named by its directory), `exit <serial> <N>` before
 the `del` of a terminal whose shell exited by itself, `ask <serial> <what>
 <choices>` when a pane asks a question (answered by `answer` on its ctl),
@@ -707,7 +708,15 @@ files, the editor's own lines), `K` (the keyboard) or `M` (the mouse); the
 action's case says where: `x`/`l` a click executed or looked at in the tag
 (its offsets count the tag's whole text, path included, as `tag` reads),
 `X`/`L` in the body, `I`/`D` text put in or taken out of the body, `i`/`d`
-of the tag. Read `n` bytes of the text, not up to a newline -- bytes here, where acme counts runes. Every offset and
+of the tag. The flag is acme's: 1 the text is a builtin's word, 2 the range
+was expanded from a click (a second record gives the original range), 4 (a
+look) the text is a file name or address, 8 (an exec) chorded: two records
+follow, the argument's text and where it came from, `<file>:#q0,#q1`.
+Written back, an `X`/`x` record executes and an `L`/`l` record looks, as
+the click would have (a chorded one with its argument); the origin letter
+written back is ignored but for `F` on `X`, which runs as the command it
+was rather than going to a bound REPL; `I`, `D`, `i` and `d` are reports and
+are refused. Read `n` bytes of the text, not up to a newline -- bytes here, where acme counts runes. Every offset and
 count pardes serves is in bytes, `#n` and `q0`/`q1` too; the event count
 follows them rather than switch alone, so an acme library reads pardes
 correctly for ASCII text and not beyond it. Offsets are bytes, but every