Re: Deleting messages via IMAP
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Monday, June 1 at 12:59 AM, quoth Ken Weingold:
>> An alternative is to simply convince mutt to hide these messages
>> from you, which you can do using limit. But it might be simpler to
>> simply have mutt do an automatic sync whenever it enters a mailbox,
>> e.g.:
>>
>> folder-hook . 'exec sync-mailbox'
>
> Fair enough. Thanks.
You're quite welcome.
> The other weird part is that after I've accessed my mail from the
> iPhone and then gone back into mutt, mutt will tell my I have new
> mail in that mailbox but then won't show there's new mail in that
> mailbox after that, so no indication in the status bar and nothing
> when I go to change folders.
That's *probably* an issue that was fixed a while back, but it's a
tough nut. Let me explain the difficulty:
The fundamental problem is one of interpretation. Namely: what does
"new" mean? There are two basic ways that IMAP can report "new"
messages: with the UNSEEN tag and the RECENT tag. UNSEEN means the
number of unread messages. RECENT means the number of new messages
*since the mailbox was last selected*. Fairly straightforward, right?
But mutt provides, with non-IMAP mailboxes, a distinction between
old-and-unread and new-and-unread. Even worse: people rely on this
distinction. In order to provide this with IMAP messages, mutt tends
to rely on the RECENT count. But RECENT is only an excellent mechanism
if (and only if) you only access mail with a single client, because
otherwise mutt has no idea when the last time each mailbox was
selected, so it has no way of knowing which of the unread messages is
old and which is truly new. Mutt used to (1.5.14 and earlier) use
RECENT. This was then decided to be unwise, for the very reason that
you've discovered: if you use another mail client, RECENT will report
that there are NO new messages.
Since mutt can cache header information (a feature that was added in
1.5.7), it's possible for mutt to be a bit more reliable in
determining what is new-and-unread and what is old-and-unread, because
with the header cache, mutt knows what messages it has already seen
(i.e. that are old) and whether they were unread or not.
It looks like you're using a relatively ancient version of mutt
(1.5.10 came out in 2005... there's been a lot of improvements since
then). If you update to a newer version of mutt, and if you turn on
header caching, it should behave a bit more predictably in the
situation where you have multiple clients accessing the same set of
IMAP mailboxes.
If you're curious, here's the relevant bug (note that it was fixed
over two years ago): http://dev.mutt.org/trac/ticket/2772
~Kyle
- --
We must not confuse dissent with disloyalty. When the loyal opposition
dies, I think the soul of America dies with it.
-- Edward R. Murrow
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!
iQIVAwUBSiPcGiuveozR/AWeAQjoEw//cp2YwCuiy2xga2hTzNTIf7VmtHPqM7lv
IXtz84x9q0w00omdml0FMjRySuH+R/xFyjQIgrXkPTpw9tHfrK9O/uuMSC5axR7/
Fwmynv729vwJRBGFMAonN1LzRf32vFNZsT07Wl7h/4to74POZ6AxNPx5wqnP6qVS
MsAMaDsxLmWE0edujuWU/qSxbwcMk97/cftuxwnsg75HorHy/yC5JqbbsdUrLitD
bnNyBzqhg3P8ko6UmPPI01nqskVQbPKY3eU2n6B8VttFJCPNGPpNhSBDNOrr2Q1c
wsv8V8Qk1GY70Gg4xK0cD9/AMmTyEkr1G+iOl3PnmUmrxBagUPTSDFhKpY5noTNF
Hm4IvuhnM0Q9Rk2UlSp7nsqwCrfFhEu3p1XMPCnjpUw1Q+joAHzqrcZ+NExxOchU
0AFCNAN1brmXQi3gSuvPCkrHQ9iYgudDV9559W7T+WeRM1L4HlX03bHXVE34vzbY
YMu5S4qjYrwkjdhklRyui09v9xjGD6wm/xFQ2CikFB6fl2SEF4vosATHW8dWIedR
R79ziHkofvsmuMEY96M4pCuOr+S0w0D9BKFI1oRIb6q9lew6eW1iuB9OvuzAL/jc
tlWW3uNlagu5OX4VcJ4jGmvSMG0QL3u63MR/Vr/ZmDV7di+QXa8Z5Cn8PY74Nq5F
HovmFCmOvnY=
=RbUo
-----END PGP SIGNATURE-----