Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Sun, 10 Jul 2022 15:10:42 +0000
Message-Id: <CLC2LS6BW4PP.5YE3QHA8D6KD@moth.falsifian.org>
Subject: Re: [PATCH aerc] Allow not marking viewed messages as seen.
From: "James Cook" <falsifian@falsifian.org>
To: "Moritz Poldrack" <moritz@poldrack.dev>, "Tim Culverhouse"
 <tim@timculverhouse.com>, <~rjarry/aerc-devel@lists.sr.ht>
References: <20220705060618.68685-1-falsifian@falsifian.org>
 <CLAGWLDXIV6M.2KH3WJUCNXDRM@TimBook-Arch>
 <CLBLJEF0Y8M8.37UIZII0LE4TG@moth.falsifian.org>
 <CLBTUDQ29NM8.1Q41X548XI78B@Archetype>
In-Reply-To: <CLBTUDQ29NM8.1Q41X548XI78B@Archetype>
Cc: 

On Sun Jul 10, 2022 at 8:18 AM UTC, Moritz Poldrack wrote:
> On Sun Jul 10, 2022 at 3:48 AM CEST, James Cook wrote:
> > Looking at that IMAP RFC link, I think the right thing to do is to fetc=
h
> > BODY.PEEK instead of BODY. Maybe aerc could always fetch BODY.PEEK
> > instead of BOD, so setting \Seen is always deliberate.
> I'd argue that BODY is the correct way to handle it and rather remove
> the \Seen flag when requested. aerc is a mail client for which this
> behaviour is the expected in most cases.

That may be more consistent with the intention behind \Seen, but here
are a few arguments for using BODY.PEEK nonetheless, at least if the
user has set the new auto-mark-read=3Dfalse:

- It removes a failure case: if aerc crashes or the Internet connection
  is lost after fetching but before unsetting \Seen.

  I really don't relish the idea of accidentally marking an email as
  \Seen --- with my workflow, that means the email drops off my radar,
  and it might have been important.

- I would argue it's simpler. One request instead of two.

- I could imagine aerc may be modified later to pre-fetch messages ---
  for example, in case the user wanted to search message bodies.


Off-topic:

I have thought a few times of using an "Archive" folder instead of
read/unread status, because I feel like I'm working against the grain.
I haven't switched for two reasons: (a) I don't like the idea of
re-transferring a (potentially large) email a couple of times just
because I decided to Archive it (mbsync, at least, isn't smart enough to
move instead of copying); and (b) I don't think my Android email client
(K-9 mail) can be made to show a complete thread combining archived and
unarchived emails, and also indicate somehow which of them are archived
vs. not. Read/unread just happens to be one of a very few flags that
email clients are designed to display.

What I'd really like is better support for IMAP (custom) labels: both
with Maildir/mbsync and on some Android client. Then I'd simply use an
"archive" or "inbox" label and be done with it.

--=20
James