Gnus development mailing list
 help / color / Atom feed
* Fetching underlying imap mail on M-g
@ 2020-06-04 17:06 Eric Abrahamsen
  2020-06-04 17:27 ` dick.r.chiang
  0 siblings, 1 reply; 5+ messages in thread
From: Eric Abrahamsen @ 2020-06-04 17:06 UTC (permalink / raw)
  To: ding

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)



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Fetching underlying imap mail on M-g
  2020-06-04 17:06 Fetching underlying imap mail on M-g Eric Abrahamsen
@ 2020-06-04 17:27 ` dick.r.chiang
  2020-06-04 17:40   ` Eric Abrahamsen
  0 siblings, 1 reply; 5+ messages in thread
From: dick.r.chiang @ 2020-06-04 17:27 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: ding

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Fetching underlying imap mail on M-g
  2020-06-04 17:27 ` dick.r.chiang
@ 2020-06-04 17:40   ` Eric Abrahamsen
  2020-06-05 15:42     ` Bob Newell
  0 siblings, 1 reply; 5+ messages in thread
From: Eric Abrahamsen @ 2020-06-04 17:40 UTC (permalink / raw)
  To: dick.r.chiang; +Cc: ding

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.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Fetching underlying imap mail on M-g
  2020-06-04 17:40   ` Eric Abrahamsen
@ 2020-06-05 15:42     ` Bob Newell
  2020-06-05 19:41       ` Eric Abrahamsen
  0 siblings, 1 reply; 5+ messages in thread
From: Bob Newell @ 2020-06-05 15:42 UTC (permalink / raw)
  To: ding


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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Fetching underlying imap mail on M-g
  2020-06-05 15:42     ` Bob Newell
@ 2020-06-05 19:41       ` Eric Abrahamsen
  0 siblings, 0 replies; 5+ messages in thread
From: Eric Abrahamsen @ 2020-06-05 19:41 UTC (permalink / raw)
  To: Bob Newell; +Cc: ding

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!


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-04 17:06 Fetching underlying imap mail on M-g Eric Abrahamsen
2020-06-04 17:27 ` dick.r.chiang
2020-06-04 17:40   ` Eric Abrahamsen
2020-06-05 15:42     ` Bob Newell
2020-06-05 19:41       ` Eric Abrahamsen

Gnus development mailing list

Archives are clonable: git clone --mirror http://inbox.vuxu.org/ding

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.emacs.gnus.general


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git