Hi James, On Thu, 21 May 2026, James Thomas wrote:
> Sacha Chua writes: > >> 2026-05-18 Emacs news > >> * Minimail version 0.5, with OAuth and more (Reddit) > >>> Gnus backends (and certainly nnimap) are synchronous. > > You can work around that using the Agent and a separate instance (as > noted in bug#78014). To illustrate, assuming that the current > (agentized) nnimap Group is the only one, at level 1 (and nothing else > on 2 either, or anywhere else, maybe): I know "group" means mailbox and I can roughly guess what "agent" is, but I have no idea what "only" or "level n" mean in this context. > - J j (unplug) > - RET (open the group unplugged) > - M-: (set-process-sentinel (start-process-shell-command "fetcher" > "*fetcher*" "emacs --batch -f gnus-child-no-server -f > gnus-group-list-all-groups -f gnus-group-quick-select-group -f > gnus-summary-exit -f gnus-group-save-newsrc") (lambda (_ event) (when > (string-equal event "finished\n") (message "Done fetching!") > (gnus-close-all-servers) (gnus-parent-read-child-newsrc)))) RET > - Now continue reading (downloaded ones) until the fetch completes. > - C-x C-s (will update it with the new arrivals instantly) This is kinda complicated, no? But I have no doubt Gnus could ship a minor more that does all that with a suitable degree of robustness. By the way, technically my approach is totally different. What you describe here is offloading IO to a subprocess (so somewhat related to thread-based concurrency), while Minimal uses the Emacs event loop for asynchronicity (a.k.a. "asyncio"). >>> From the moment you call, say, gnus-summary-display-article until >>> the moment the article finishes downloading, it blocks. > > This can also be side-stepped by marking articles as downloadable (while > reading, then 'updating' it) and including one of the > 'gnus-agent-fetch-' commands in the above. > > What's more, Gnus's parent-child paradigm lets you mix and match not > just the parallelism thus, but also _distribution_ - if you use multiple > devices - together in a fine-grained way. You seem to be describing the "offline email" approach I alluded to in the Reddit comment. Some people like it but it's something I, for one, explicitly don't want. A transparent cache would be fine, though. >>> (and main difference to Gnus) is that it's simple and intuitive. > > Granted; but there might also therefore be no room to 'grow' in > expertise, as with Emacs itself. Not everyone wants to be an email (or Gnus) expert. At any rate, you can set up and learn Minimail in 15 minutes and then spend the rest of the afternoon studying its source code, which is quite interesting IMO. > (I personally don't use the parallelism part, being content to check > mail/news only occassionally - in fact, wanting it only so) > > But those for whom this is important might be able to decide and work-in > a simple interface for all this (btw this procedure is applicable to > _any_ backend, not just nnimap). > > Then perhaps there might be a 'Greenspun's Eleventh' meant for those > reinventing Gnus? :-) Fortunately I'm very far from attempting such a thing. I just want a simple online IMAP mail client. By the way, I would likely use Gnus for RSS/Atom if it would load stuff in the background without blocking. > (CC-ing ding gnus FTR) --- via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)
