Subject: Re: bug#54158: 28.0.91; duplicate mail downloads in Gnus (IMAP)

From: Andrew Cohen <[email-masked]>
Date: Sun, 20 Mar 2022 05:52:04 +0800

On Sat, Mar 19 2022, Roland Winkler wrote:
>On Sat, Mar 19 2022, Andrew Cohen wrote:

[...]

>> So I think this might fix it (although I don't have a setup available
>> to test it).

> Thank you!  I can confirm: I identified one scenario with emails I send
>to myself such that they go into different folders on the IMAP server.
>Then downloading these messages with Gnus from Emacs 28.0.91 gives me
>reproducibly the duplicate mail downloads as described in the original
>post.  When I apply Andrew's patch to `mail-source-fetch-imap' the
>downloads happen as expected, properly deleting the messages on the
>server after download, as confirmed also with imap-log bound to to.
>So for this one test case the patch appears to solve the problem.

Great! 

>The patch may require more testing and also checking the code by someone
>who knows what is supposed to happen in such an imap session.  

More testing would be good---but I suspect the number of users of a list
of mailboxes with imap is small :) Fortunately the patch is quite minor
and I'm pretty confident that this change is the right thing.

My patch also fixes another bug---the header identifying the originating
mailbox was getting set improperly (to the list of mailboxes rather than
the actual mailbox).

>I am surprised that `mail-source-fetch-imap' in Gnus from Emacs 27.2
>and from Emacs 28.0.91 are essentially the same (from all I can tell).
>So I am wondering why `mail-source-fetch-imap' in Gnus from Emacs 27.2
>was behaving as expected; but the bug showed up only in Emacs 28.  Can
>this be in subtle ways related to the fact that mail-source.el in Emacs
>27 used dynamic binding, whereas in Emacs 28 it uses lexical binding,
>as speculated previously by Eric?

This is indeed a mystery. If you are excited about getting to the bottom
of it you could try enabling the log with emacs-27 and post the result
of your scenario. The problem was the variable 'remove was accumulating
UIDs from prior iterations of the loop. 

-- 
Andrew Cohen