]> granicus.if.org Git - neomutt/commit
Fix dropped new mail notifications when an EXPUNGE_PENDING is set
authorKevin McCarthy <kevin@8t8.us>
Wed, 5 Jun 2019 21:04:55 +0000 (14:04 -0700)
committerRichard Russon <rich@flatcap.org>
Thu, 6 Jun 2019 23:59:11 +0000 (00:59 +0100)
commit5b26abc547b44ab1a84afb0e9ce6969ffa0904a5
tree7b6b83fdc2e7a4b8b4099d7edca00fb15e4f1eb3
parent91d57b42c633e178e8ce259527f83695d0dc7483
Fix dropped new mail notifications when an EXPUNGE_PENDING is set

Prior to the fetch_headers rework and introduction of
idata->max_msn (starting around e0376c75), cmd_handle_untagged() was
looking directly at ctx->msgcount, which isn't fixed up until
imap_expunge_mailbox().  At that time, more care had to be taken
inbetween handling the EXPUNGE message and the actual expunge of the
mailbox because of the discrepency between server state and mailbox
context state.

idata->max_msn is now decremented during the processing of EXPUNGE and
VANISHED notices from the server, so reflect "current" state.  So,
when we receive an EXISTS notice, we no longer need the checks for
expunge state and can always set the NEWMAIL_PENDING flag.

Additionally, fix imap_cmd_finish() to retain the IMAP_NEWMAIL_PENDING
flag after handling an expunge.  The expunge does not grab new
messages so dropping the flag would cause mutt to forget the new mail
status until another EXISTS command.

Since this is a stable branch fix, I'm leaving the either/or
processing of expunge versus new mail in imap_cmd_finish().  However,
I don't see why this has to be done in two calls.  I may rework that
in master to process an expunge and then the new mail one after the
other.

Co-authored-by: Richard Russon <rich@flatcap.org>
imap/command.c