The docs say how a follower sees repeats, what caps Newcol, that Restore starts undo afresh, where dot ends after data and sel, and where $ sits on a CRLF line

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

1 files changed, 12 insertions, 5 deletions

diff --git a/docs/fs.md b/docs/fs.md
index f35bb3f6..e988b87f 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -135,7 +135,9 @@ Existing Plan9port/v9fs clients need a userspace bridge for QUIC.
 /layout      one line per column (16 at most; the board 6; Newcol past that fails,
              `no space for a column: 16 max`, ENOSPC; and each at least 10 cells
              wide, so Newcol from a column under 20 fails `this one is too
-             narrow to split`, ENOSPC), left to right: serial index x width current|notcurrent
+             narrow to split`, ENOSPC; the root's Newcol halves the active column,
+             so reaching 16 means running Newcol from the widest column's tag),
+             left to right: serial index x width current|notcurrent
              (the column with the keyboard now) empty|full pane-serials...; then active
              <serial>: acme's activecol, which the keyboard leaving for another column's
              tag does not move, so the two can differ -- the active column, where
@@ -220,7 +222,8 @@ 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>`. Restored panes have new serials (`restored <old>
+`restore <path>`. Undo history does not survive a Restore: a restored pane
+starts with none. 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 saying how it ended,
@@ -575,7 +578,9 @@ terminal's `body` is its history as plain text, frozen per open, in logical
 lines: a row the terminal wrapped is joined back to the row before it (the
 wrap is ghostty's, as `pty/run`'s output unwraps), and the last line ends
 with a newline. `sel`
-reads the selected text and writing it replaces the selection. `errors`
+reads the selected text and writing it replaces the selection, leaving dot
+just past the text written (a `data` write moves dot as its text moves it,
+so a dot at the address it wrote at ends just past that text too). `errors`
 appends to the directory's `+Errors` pane; with no room for that pane in
 any column, what it would have shown is logged as `msg` records instead, a
 line each, and the write still succeeds. Holding `event` open redirects the
@@ -705,7 +710,8 @@ lines, so `^` and `$` match at the start and end of any line, `.` and a
 negated class never match a newline, and `$` also matches at the end of a
 text with no final newline. A pattern that names a newline (`\n`) runs over
 the whole text instead, its `.` kept to one line; there a leading `^` still
-matches at every line start, and `$` may stand just before a `\n` (where it
+matches at every line start (`$` on a CRLF line sits before the `\r`,
+as the line's end is its `\r\n`), and `$` may stand just before a `\n` (where it
 changes nothing). Any other `^` or `$` in such a pattern, `(^|\n)def` or
 `a\nb$`, is refused, EINVAL, with `bad regular expression: in a pattern with \n, ^ can only come first and $
 only just before a \n`, since mvzr would read it as the start or end of the
@@ -884,7 +890,8 @@ itself, is counted rather than repeated (`err 3 addr: no match for regexp
 write does not push the rest out of the ring. A record a follower has
 already read is never rewritten: the next repeat is a line of its own
 carrying the running total, `(x5)`, and counting goes on from there, so a
-follower sees each count as a new line. Through a kernel mount a client sees only an errno, which 9ns reads from the
+follower sees each count as a new line: with a follower attached, a repeat
+is a new line carrying its `(xN)` count, never an edit of the one read. Through a kernel mount a client sees only an errno, which 9ns reads from the
 error's words (cloud9's 9ns/src/nine.zig, `enameToErrno`): a malformed write
 -- an unknown or ill-formed control message, `bad address syntax`, `bad
 regular expression` -- is EINVAL; a lock another open holds, EBUSY; a pane