Edit's x, y and s match whole runes, as addresses do

mvzr matches bytes, and only the addr path widened a match to runes, so
,x/./a/|/ on é split it into invalid UTF-8 and ,s/./X/g gave a combining
sequence four X's. Edit's matches now go through the same rune alignment
(and an empty match steps a rune, not a byte). runeStart no longer walks a
stray continuation byte back onto the ASCII before it: an invalid byte is
a place of its own.

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

1 files changed, 1 insertions, 1 deletions

diff --git a/docs/fs.md b/docs/fs.md
index c95a45db..428cc84c 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -664,7 +664,7 @@ inside a multibyte rune and never widened to a grapheme cluster: a `#n`
 inside a rune snaps back to its start, a `line:col` likewise, a search's
 match covers the runes it touches, and a copy of addr to dot keeps its
 runes, so a lone combining mark or the `\r` of a CRLF is addressable on its
-own; `addr` reads back the snapped offset. (How the terminal draws such a
+own (an Edit's `x`, `y` and `s` match the same way: `.` is one rune); `addr` reads back the snapped offset. (How the terminal draws such a
 text, a cluster to a cell, is apart from this.) A click in a
 tag gives offsets into the whole tag as `tag` reads it, the path first.) An
 open freezes the ring's text the way `/screen` freezes a frame: reads walk it