@bobfrankston/rmfmail 1.1.71 → 1.1.73

package/packages/mailx-imap/index.ts

@@ -3057,7 +3057,13 @@ export class ImapManager extends EventEmitter {
                             await api.setFlags(folder.path, action.uid, action.flags || []);
                             console.log(`  [api] ${accountId}: flags synced UID ${action.uid}`);
                         } else if ((action.action === "delete" || action.action === "trash") && api.trashMessage) {
-                            await api.trashMessage(folder.path, action.uid);
+                            // Pass the stored Gmail message id (provider_id) so
+                            // the provider doesn't fall back to its capped
+                            // list-and-hash search — that search misses any
+                            // message past the most-recent ~1000 in a large
+                            // mailbox, fails, and the deletion un-happens.
+                            const env: any = this.db.getMessageByUid(accountId, action.uid);
+                            await api.trashMessage(folder.path, action.uid, env?.providerId);
                             console.log(`  [api] ${accountId}: trashed UID ${action.uid} from ${folder.path}`);
                         } else if (action.action === "move" && api.moveMessage) {
                             const target = folders.find(f => f.id === action.targetFolderId);
@@ -3067,7 +3073,8 @@ export class ImapManager extends EventEmitter {
                                 this.db.completeSyncAction(action.id);
                                 continue;
                             }
-                            await api.moveMessage(folder.path, action.uid, target.path);
+                            const env: any = this.db.getMessageByUid(accountId, action.uid);
+                            await api.moveMessage(folder.path, action.uid, target.path, env?.providerId);
                             console.log(`  [api] ${accountId}: moved UID ${action.uid} ${folder.path} → ${target.path}`);
                         } else {
                             // Unsupported action on Gmail. After 5 retries, drop it

package/packages/mailx-imap/package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "@bobfrankston/mailx-imap",
-  "version": "0.1.50",
+  "version": "0.1.51",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "@bobfrankston/mailx-imap",
-      "version": "0.1.50",
+      "version": "0.1.51",
       "license": "ISC",
       "dependencies": {
         "@bobfrankston/iflow-direct": "^0.1.27",

package/packages/mailx-imap/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bobfrankston/mailx-imap",
-  "version": "0.1.50",
+  "version": "0.1.51",
   "type": "module",
   "main": "index.js",
   "types": "index.d.ts",

package/packages/mailx-settings/docs/multi-view.md

@@ -0,0 +1,81 @@
+# Multi-view: tabs, tear-off, separate windows
+
+Goal: multiple **views** over one backend — like Thunderbird/Outlook — so the
+user can keep a message open while working the list, compare two folders, etc.
+NOT multiple daemon instances (`--another` already exists for that, and a
+second daemon means a second DB connection — contention, not what's wanted).
+
+## Key fact: reminders already spawn separate native windows
+
+`MailxService.showReminderPopup` → injected `popupFn` → msger
+`showMessageBoxEx` opens a **real OS WebView window** fed a self-contained HTML
+document (`rawHtml: true`: the caller ships a full HTML doc with its own button
+row + an inline script that posts results back over the wry bridge). It returns
+a handle with `pid` + `close()`.
+
+Consequence: msger spawning extra native windows is **not** the blocker. The
+"popups don't inherit the custom protocol" limitation only blocks a window that
+must load the *multi-file app* (index.html + app.bundle.js + CSS + importmap
+deps, all served from `msger.localhost`). A **single rendered view** is
+self-contained content — the reminder shape.
+
+So:
+- **Torn-off READ-ONLY message reader** = the reminder mechanism. The daemon
+  already has rendered `bodyHtml` from `getMessage`; wrap header + sanitized
+  body as a standalone HTML doc, hand to `showMessageBoxEx`. No custom
+  protocol, no second IPC channel. Cheap.
+- **Torn-off INTERACTIVE view** (reply / navigate / delete / live sync
+  updates) needs a real IPC channel back to the daemon → msger multi-channel
+  work. Expensive. Deferred.
+
+## Three view modes, one backend
+
+1. **Tabs** inside the main window — one WebView, one IPC channel, a tab strip;
+   each tab is an independent three-pane (or a single-message view). Pure
+   client work.
+2. **Tear-off** — detach a tab into its own OS window.
+   - Read-only message tab → `showMessageBoxEx` + `rawHtml` (reminder path).
+   - Interactive tab → needs msger multi-channel IPC (later).
+3. **Re-dock** — drag a torn-off window's content back in as a tab. For the
+   read-only reader this is just: close the popup, re-open the message as an
+   in-window tab. For interactive, follows whatever (2) settles on.
+
+## Tabs architecture (the real work)
+
+Today the list view is module-level global state in `client/components/
+message-list.ts` — `currentAccountId`, `currentFolderId`, `searchMode`,
+`currentSearchQuery`, `positionMemory`, `listCache` — and `message-state.ts` is
+a single global "source of truth" for the list+viewer. One window = one view.
+
+Tabs require that view-state to become **per-tab**:
+
+- **Per-tab:** selected account+folder (or search), selected message, list
+  scroll position, the `message-state` instance, sort order, flagged-only
+  toggle.
+- **Shared (stays global):** the IPC connection + sync event stream, folder
+  counts, the contacts cache, settings, the parsed-body LRU on the daemon.
+  Sync/new-mail events broadcast to every tab; each tab decides if the event
+  touches its folder.
+
+Shape: a `TabManager` owning an array of `ViewTab`, each `ViewTab` holding its
+own `MessageListState` + the DOM subtree for its three-pane. Only the active
+tab's subtree is in layout; inactive tabs keep their DOM detached (cheap) or
+their state and rebuild on activate. `message-list.ts` functions take a
+`ViewTab` (or read `TabManager.active`) instead of the module globals.
+
+## Staging
+
+1. **Tab strip + per-tab three-pane.** Extract the message-list globals into a
+   `ViewTab`/`TabManager`; render a tab strip; New Tab opens another inbox
+   view. The bulk of the work and the architectural commit.
+2. **Open-in-new-tab** for a message (and a folder). Exercises per-tab state on
+   the simplest views.
+3. **Tear-off a read-only message tab** → `showMessageBoxEx` standalone window
+   (reminder mechanism). Re-dock = reopen as a tab.
+4. **Interactive tear-off / true second app window.** Needs msger to let a
+   spawned window inherit the custom protocol AND carry its own IPC channel,
+   plus the daemon multiplexing IPC and broadcasting events to N channels.
+   Separate, cross-component project — do last, only if the read-only
+   tear-off proves insufficient.
+
+Start at stage 1. Each stage is independently shippable.

package/packages/mailx-settings/docs/search.md

@@ -19,7 +19,7 @@ These are parsed by mailx before dispatch, so they apply to all three scopes:
 | `from:bob` | Match sender substring |
 | `to:eleanor` | Match recipient substring |
 | `subject:lunch` | Match subject substring (everything until the next `keyword:` or end) |
-| `/regex/` | Client-side regex over the currently-visible rows. Local only — never sent to the server. |
+| `/regex/` | Client-side regex over the currently-visible rows. **Case-insensitive.** Local only — never sent to the server. |
 
 The remaining (unqualified) text becomes the **body** search term in the server query, or a free-text FTS5 phrase in local mode.
 
@@ -80,6 +80,10 @@ So if you typed `bob AND eleanor` on bobma and got results, what likely happened
 
 That explains the asymmetry you may have noticed: `bob AND eleanor` "worked" against bobma (literal-text coincidence) but not against Gmail (no IMAP/API call ever fired).
 
+## Case sensitivity
+
+All three modes are **case-insensitive** — local FTS5, IMAP server SEARCH, and `/regex/` filtering alike. `Lunch`, `lunch`, and `LUNCH` match the same messages. There's no way to force a case-sensitive search.
+
 ## Limitations
 
 - **No regex on the server side** (any provider). `/pattern/` only filters the visible local rows.

package/packages/mailx-settings/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bobfrankston/mailx-settings",
-  "version": "0.1.17",
+  "version": "0.1.19",
   "type": "module",
   "main": "index.js",
   "types": "index.d.ts",

package/packages/mailx-store/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bobfrankston/mailx-store",
-  "version": "0.1.28",
+  "version": "0.1.29",
   "type": "module",
   "main": "index.js",
   "types": "index.d.ts",