Fetching underlying imap mail on M-g

Fetching underlying imap mail on M-g

[Eric Abrahamsen]

I'm posting this here just in case it's useful to anyone; I'm finding it
very handy.

I store my IMAP mail in a local dovecot, updated using "mbsync". I've
got several IMAP accounts, with a lot of groups, and was getting sick of
switching to the shell and running "mbsync -a", then back to Gnus, and
eventually "g". I tried a few things with an asynchronous update from
withing Gnus, etc: nothing really felt right. I decided what I wanted
was to be able to do a "full update" (including switching to the shell)
if I wanted, but also do a "spot update" when hitting M-g on a
group/topic/etc. So I added the function below to
`gnus-get-new-news-hook'. Basically it checks if I'm only updating a
handful of groups, and calls the underlying "mbsync" to actually fetch
mail from the server. You could also do this for several accounts, using
`make-process' for asynchronous updates.

Hope it's of interest to someone...


(defun my-gnus-retrieve-group ()
  (when (memq this-command '(gnus-topic-get-new-news-this-topic
			     gnus-group-get-new-news-this-group))
    (let ((pr-groups
	   (seq-filter (lambda (g)
			 (string-match "^nnimap\\+NPR:" g))
		       (gnus-group-process-prefix
			current-prefix-arg))))
      (message "Fetching mail for %d group(s)" (length pr-groups))
      (when pr-groups
	(call-process
	 nil nil nil
	 "/usr/bin/mbsync"
	 (mapconcat (lambda (g)
		      (format "pr:%s"
			      (replace-regexp-in-string
			       "\\." "/"
			       (nth 1 (split-string g ":")))))
		    pr-groups " "))))))
                               
(add-hook 'gnus-get-new-news-hook #'my-gnus-retrieve-group)

Re: Fetching underlying imap mail on M-g

[dick.r.chiang]

I wonder how many others manually runs mbsync, or similarly eschew
running mbsync from cron or systemctl which I'd surmise most
people do.

Re: Fetching underlying imap mail on M-g

[Eric Abrahamsen]

dick.r.chiang@gmail.com writes:

> I wonder how many others manually runs mbsync, or similarly eschew
> running mbsync from cron or systemctl which I'd surmise most 
> people do.

I don't know why, but I've never liked having mbsync run automatically.
Some weird psychological thing, I guess -- I like being able to think
"now I'm going to check my mail". Plus I'm offline quite a bit.

Re: Fetching underlying imap mail on M-g

[Bob Newell]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> Some weird psychological thing, I guess -- I like being able to think
> "now I'm going to check my mail". Plus I'm offline quite a bit.

I can only speak to my own psychology, but I think "offline quite a
bit" defines the use case in a critical way.

I've never been able to realistically use a dovecot-like
solution which implies local storage of email because I sync
environments across something like 8 devices and I'm not
willing to replicated gigabytes of email on all of them, nor
do I want to maintain different setups on different devices to
the extent possible. It would all just get to be too much to
manage.

On the other hand, I'm offline very seldom, so I'm willing to
forego the ability to process email while offline, and that's
a crucial distinction.

As to psychology: I don't want to check email too often, as it
becomes a great distraction and interruption of a flow
state. So--- perhaps perversely--- I don't make checking email
be too easily done. It's entirely manual and entirely within
Gnus, which means relatively slow IMAP access. This means it's
just easier to keep writing or editing rather than stop for
email. Please, no 'you have mail!' jingles. My mode line does
silently show how many new unread emails I have, but that's
read from a drop file generated by an external process that
only runs once an hour.

-- 
Bob Newell
Honolulu, Hawai`i

- Via GNU/Linux/Emacs/Gnus/BBDB

Re: Fetching underlying imap mail on M-g

[Eric Abrahamsen]

Bob Newell <bobnewell@bobnewell.net> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>> Some weird psychological thing, I guess -- I like being able to think
>> "now I'm going to check my mail". Plus I'm offline quite a bit.
>
> I can only speak to my own psychology, but I think "offline quite a
> bit" defines the use case in a critical way.
>
> I've never been able to realistically use a dovecot-like
> solution which implies local storage of email because I sync
> environments across something like 8 devices and I'm not
> willing to replicated gigabytes of email on all of them, nor
> do I want to maintain different setups on different devices to
> the extent possible. It would all just get to be too much to
> manage.

I hear this. I have one laptop, one desktop, and one phone. I have the
laptop set to sync everything locally, the desktop set to talk directly
to the remote server (it's never offline, anyway), and the phone uses K9
to read mail, but I have it set to never mark anything as read -- I
treat it as a read-only terminal.

If I had eight devices, this would look very different :)

> On the other hand, I'm offline very seldom, so I'm willing to
> forego the ability to process email while offline, and that's
> a crucial distinction.
>
> As to psychology: I don't want to check email too often, as it
> becomes a great distraction and interruption of a flow
> state. So--- perhaps perversely--- I don't make checking email
> be too easily done. It's entirely manual and entirely within
> Gnus, which means relatively slow IMAP access. This means it's
> just easier to keep writing or editing rather than stop for
> email. Please, no 'you have mail!' jingles. My mode line does
> silently show how many new unread emails I have, but that's
> read from a drop file generated by an external process that
> only runs once an hour.

I have the same instincts, but have not been quite as severe with
myself. I also want checking email to be a very manual, very intentional
act. But sometimes I know that I'll have a reply coming in within
minutes, and this wrapper on "M-g" lets me handle those cases without
feeling like I'm "cheating".

Thanks for your comments!