help: the search block's (i) on its header, a 12 px mark, and a real search page

help/C/org.udpscope.app/trigger.page

@@ -114,12 +114,54 @@
 
   <section id="search">
     <title>Search the buffer</title>
-    <p><gui>Search the buffer</gui> runs the same condition over the whole retained ring and
-    lists every place it holds. The arrows step through hits; each step pauses on the hit,
-    centred, exactly as the Pause button does. Up to 16 hits in the visible window are marked
-    on every row; when there are more the panel says how many and suggests zooming in. The
-    search uses the trigger's own condition, set in one place, so a hit is by construction an
-    instant the trigger would have fired.</p>
+    <p><gui>Search the buffer</gui>, at the foot of the trigger panel and collapsed until you open
+    it, answers the question the trigger answers — <em>where does this condition hold?</em> — over
+    the <em>whole</em> retained buffer rather than at the live edge. It runs the trigger's own
+    evaluator over the ring in stream order, so a <gui>hit</gui> is not a level you point at: it is
+    an <em>instant</em> the trigger would have fired on, timed the way an acquisition would have
+    timed it. A pulse-width finding, for instance, is the closing edge of a qualifying excursion,
+    not the excursion itself.</p>
+
+    <p>The condition is the one the rest of the panel is set to — the same signal, shape, level and
+    options — so there is no second condition to keep in step: change the panel and the next search
+    asks the new question. Nothing is searched until you ask, and the status line says
+    <gui>not searched</gui>.</p>
+
+    <steps>
+      <item>
+        <p>Set the condition above, then press <gui>Search</gui>. Covering the whole ring takes a
+        moment, and the scan runs in chunks so the stream keeps arriving while it does; the status
+        line counts the ground covered — <gui>scanning 1.2 s of 8.0 s, 40 found</gui>.
+        <gui>Stop</gui> ends a scan early and keeps the hits found so far.</p>
+      </item>
+      <item>
+        <p>Step through the hits with the arrows either side of the position readout
+        (<gui>3 of 40</gui>). The first <gui>next</gui> goes to the first hit, and the ends do not
+        wrap — a wrap from the last hit to the first would look exactly like the view not having
+        moved. Each step <em>pauses</em> on its hit, centred, exactly as the Pause button does, so
+        what you read is the frozen window cut around that instant; press the pause button again to
+        go back to the stream.</p>
+      </item>
+      <item>
+        <p>Every plot row marks the hits that fall in the window, up to sixteen of them. When more
+        are in view the pane says so and suggests zooming in — <gui>16 of 38 marks shown — zoom in
+        to see the rest</gui> — and when the selected hit has scrolled off the window it says that
+        instead. A hit the live stream has since overwritten reads <gui>no longer in the buffer</gui>
+        beside its position.</p>
+      </item>
+    </steps>
+
+    <p>How a scan ended is part of the answer: <gui>N found in 8.0 s</gui> when it covered the whole
+    ring; <gui>N found; the stream overtook the oldest samples</gui> when the producer overwrote
+    samples before the scan reached them, so the count is of what was left; and
+    <gui>N found (the limit) in the newest …</gui> when a condition that holds almost everywhere —
+    an edge on a noisy signal — reached the ten-thousand-hit ceiling. The last is a stop, not a
+    crash: a hit list nobody could navigate is not worth building.</p>
+
+    <p>A result describes the ring it was taken from, so it is <em>dropped</em> when that ring is
+    replaced: a new <gui>CONFIG</gui> from the source, or a change to the signal set, re-describes
+    the stream and clears the hits. The condition above is untouched — only the answer to it
+    is.</p>
   </section>
 
   <section id="knowing">