@bobfrankston/rmfmail 1.2.296 → 1.2.297

package/.commitmsg

@@ -1,29 +1,32 @@
-A star set on the phone now reaches the desktop in seconds, not minutes
+Reading a message outranks syncing it; a filter is not a selection
 
-Bob 2026-08-29: "how long should it take for a * on the phone to get to my
-desktop?" Measured, on his own log: a median of 5 minutes and up to 20.
+Two things Bob hit on 2026-08-29.
 
-Why: gal.iecc.com does not advertise NOTIFY, so the desktop watches INBOX with
-plain IDLE. The server DOES push a flag change there as an unsolicited
-`* 1234 FETCH (FLAGS (\Seen \Flagged))` — iflow-direct dropped it (fixed in
-0.1.67), and mailx had nothing to receive it with. The 5-minute quick check
-could not help either: it is a STATUS poll, and MESSAGES / UNSEEN / UIDNEXT do
-not move when a message is starred. So the only path was the periodic full
-sync's QRESYNC pass — which is why the numbers above are the sync cadence
-rather than any property of flags.
+**"If I look at a letter while sync, things get confused. Eventually it reports
+an error rather than retrying. Viewing the body should get priority instead of
+waiting for sync."** Both halves were real:
 
-The IDLE watcher now takes `onFlagChange` and, debounced 1.5 s, runs the
-folder's normal QRESYNC pass — the same one that already reconciles flags and
-took 53 ms in that log. Marking ten messages read on the phone arrives as ten
-pushes and costs one pass. Our own STOREs bounce back as flag pushes too, so
-the handler skips while this account has sync actions draining; the local store
-already has those.
+- Lanes are strictly sequential, and a click-time body fetch went on the tail
+  of the fast lane behind whatever background work was already queued.
+  `withConnection` now takes `priority`, which puts the task at the FRONT of
+  its lane; the interactive fetch uses it and a 30 s cap instead of 90 s. It
+  still cannot preempt the command in flight — an IMAP command cannot be
+  cancelled without dropping the connection — but it no longer waits out the
+  backlog.
+- `fetchMessageBody` swallowed every error into `null`. To the reconciler that
+  means "the server has no body for this message", which is classified
+  non-transient, skips the 3-attempt retry budget, and paints a banner. A lane
+  timeout says nothing about whether the message has a body: transient errors
+  (timeout, dropped socket, discarded client) now propagate, so the existing
+  retry-with-backoff applies and the reader gets the message instead of an
+  error. Only a genuine "no body here" still arms the prefetch backoff — a
+  timeout used to arm it too, poisoning the next view for up to 12 h.
 
-INBOX only, because IDLE watches one mailbox per connection. Flags changed in
-other folders still wait for that folder's turn in the sync cycle.
-
-Also in this build: the log noise behind it. `[search]` / `[fetch]` per-command
-lines moved behind iflow's existing `verbose` flag, and the repeated
-per-folder reconcile lines now go through `logIfChanged` — first occurrence,
-every change, and an hourly restatement — instead of once per folder per cycle
-forever. On Android each of those lines was an HTTP request to the log server.
+**"If I press * on search it shouldn't automatically select those letters, just
+show them."** Nothing was selected — the flagged-only filter washed the whole
+list in the flag colour (added 2026-06-26 to make the filter unmistakable), and
+a coloured background over rows is exactly how this list says "chosen". The
+wash is gone; the filter now announces itself above the list, by name:
+"Showing flagged (★) messages only — click to show everything", and clicking it
+clears the filter. Same chip covers the priority-senders filter, which had the
+same shape.

package/client/app.bundle.js

@@ -13482,6 +13482,23 @@ function syncFilterFlaggedButton() {
   btn.classList.toggle("active", !!optFlagged?.checked);
   btn.setAttribute("aria-pressed", optFlagged?.checked ? "true" : "false");
 }
+function syncFilterChip() {
+  const chip = document.getElementById("ml-filter-chip");
+  if (!chip) return;
+  const flagged = !!document.getElementById("opt-flagged")?.checked;
+  const priority = !!document.getElementById("opt-priority-only")?.checked;
+  const names = [flagged ? "flagged (\u2605) messages" : "", priority ? "priority senders" : ""].filter(Boolean);
+  if (!names.length) {
+    chip.hidden = true;
+    return;
+  }
+  chip.hidden = false;
+  chip.textContent = "Showing " + names.join(" and ") + " only \u2014 click to show everything";
+  chip.title = "Clear the list filter";
+}
+document.getElementById("ml-filter-chip")?.addEventListener("click", () => {
+  document.dispatchEvent(new CustomEvent("mailx-clear-list-filters"));
+});
 function applyFlaggedFilter(on) {
   try {
     logClientEvent("applyFlaggedFilter", { on, caller: new Error().stack?.split("\n").slice(2, 5).join(" | ") });
@@ -13493,6 +13510,7 @@ function applyFlaggedFilter(on) {
   else body?.classList.remove("flagged-only");
   localStorage.setItem("mailx-flagged", String(on));
   syncFilterFlaggedButton();
+  syncFilterChip();
   reloadCurrentFolder();
 }
 optFlagged?.addEventListener("change", () => {
@@ -13502,6 +13520,7 @@ document.getElementById("btn-filter-flagged")?.addEventListener("click", () => {
   applyFlaggedFilter(!optFlagged?.checked);
 });
 syncFilterFlaggedButton();
+syncFilterChip();
 var optPriorityOnly = document.getElementById("opt-priority-only");
 if (optPriorityOnly) {
   optPriorityOnly.checked = localStorage.getItem("mailx-priority-only") === "true";
@@ -13512,6 +13531,7 @@ if (optPriorityOnly) {
     if (optPriorityOnly.checked) body?.classList.add("priority-only");
     else body?.classList.remove("priority-only");
     localStorage.setItem("mailx-priority-only", String(optPriorityOnly.checked));
+    syncFilterChip();
   });
 }
 document.addEventListener("mailx-clear-list-filters", () => {