Gnus development mailing list
 help / color / mirror / Atom feed
From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: Bob Newell <bobnewell@bobnewell.net>
Cc: ding@gnus.org
Subject: Re: Fetching underlying imap mail on M-g
Date: Fri, 05 Jun 2020 12:41:57 -0700	[thread overview]
Message-ID: <87tuzpti4a.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <s6jv9k534ed.fsf@emailmessageidheader.nil> (Bob Newell's message of "Fri, 05 Jun 2020 05:42:50 -1000")

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!


      reply	other threads:[~2020-06-05 19:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-04 17:06 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 [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tuzpti4a.fsf@ericabrahamsen.net \
    --to=eric@ericabrahamsen.net \
    --cc=bobnewell@bobnewell.net \
    --cc=ding@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).