messages: a fixed log of what the rows said, and a word to read it back

A message row is cleared by the next keystroke, so anything reported while you
were looking at another pane was gone before you could read it — a save that
failed, a watcher's reload, a builtin's complaint. `setMessage` now records
into a fixed ring first: no allocation and no failure path, because it sits
underneath `reportError`, which is reached from sites that are reporting an
allocation failure. `Messages` (`SPC h m`) reads it back oldest-first.

Three things an adversarial pass found, each of which defeated the feature:

PROGRESS IS NOT A MESSAGE. A language server emits `Indexing 47%` several
times a second, and every tick is a distinct string BY CONSTRUCTION, so no
de-duplication can collapse it: at the client's one-per-150ms throttle it
takes about nineteen seconds to push every real message out of the ring. A log
that one indexing run empties is not a log. That path is `setStatus` now —
the row, and nothing else.

THE CLOCK MADE EVERY HOST MESSAGE UNIQUE. `message.stamp` prefixes `HH:MM:SS`,
so `saved /x.zig` at 14:32:07 and at :09 compared unequal and the ring filled
with rows that look identical and each say (x1) — exactly the case the
de-duplication exists for. It compares `message.body` now, the row without its
clock, and the newest wording wins so the row carries the last time it
happened rather than the first. It also keys on the PANE (one pane's failure
must not be recorded as another's) and compares the truncated form, so two
identical messages over 256 bytes stop being two rows.

AND THE CAPACITY BELONGS IN limits.zig. 128 entries is 32.75 KiB that is
allocated whether or not anybody reads it — 8.5% of the ESP32-P4's whole
384 KiB heap, about the size of its effect ring. The board takes sixteen.

The builtins/leader goldens move because the listing gains a row, and
builtins.snap middle-clicks a SCREEN COORDINATE that Tutor moved out of; both
updated selectively and verified against a fresh run.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_016Q4RATpafkwahrovHQLKRf

1 files changed, 19 insertions, 0 deletions

diff --git a/src/message.zig b/src/message.zig
index 0935ce96..0855c448 100644
--- a/src/message.zig
+++ b/src/message.zig
@@ -43,6 +43,25 @@ extern "c" fn localtime_r(timep: *const libc.time_t, result: *Tm) ?*Tm;
 /// clock cannot live in a golden — but a message that vanished under the
 /// harness could not be pinned at all, so the row still renders, still says
 /// what happened, and still occupies the same columns.
+/// The stamped text WITHOUT its clock — what two of these rows have in common
+/// when they say the same thing at different times.
+///
+/// The message log de-duplicates on this rather than on the whole row, because
+/// the clock makes every host message unique by construction: `saved x` at
+/// 14:32:07 and at 14:32:09 are different strings, so a watched file rebuilt
+/// in a loop filled the ring with identical-looking rows, each counted once.
+/// That is exactly the case the de-duplication exists for.
+pub fn body(text: []const u8) []const u8 {
+    // `HH:MM:SS  ` — ten bytes, digits or the `--:--:--` the harness blanks
+    // them to. Anything else is a message that was never stamped.
+    if (text.len < 10) return text;
+    if (text[2] != ':' or text[5] != ':' or text[8] != ' ' or text[9] != ' ') return text;
+    for ([_]usize{ 0, 1, 3, 4, 6, 7 }) |i| {
+        if (!std.ascii.isDigit(text[i]) and text[i] != '-') return text;
+    }
+    return text[10..];
+}
+
 pub fn stamp(buf: []u8, verb: []const u8, subject: []const u8) []const u8 {
     var clock: [8]u8 = "--:--:--".*;
     const notime = if (libc.getenv("PARDES_NOTIME")) |v| std.mem.span(v).len != 0 else false;