[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#35443: 27.0.50; Gnus (nnimap) shows "ghost" messages in summary buff
From: |
Eric Abrahamsen |
Subject: |
bug#35443: 27.0.50; Gnus (nnimap) shows "ghost" messages in summary buffer |
Date: |
Thu, 11 Jul 2019 13:28:37 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> On 06/23/19 14:23 PM, Lars Ingebrigtsen wrote:
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>>> Did you get any further in fixing this nnimap parsing bug?
>>>
>>> Here's a whack at it. I tried to make sure that it would handle unwanted
>>> FETCH responses whether they came before or after (or in the middle of)
>>> the wanted FETCH responses, but I'm not in love with checking the header
>>> regexp this way.
>>
>> Well, I think it's OK...
>>
>>> Because this IMAP server feature is very closely focused on adding a
>>> flag in case of attachment (and because Gnus never explicitly requests
>>> this flag, though I'd sure like to in the future), another more targeted
>>> approach would be to simply delete any lines containing
>>> $Has\(No\)?Attachment, assuming that these FETCH responses will only
>>> take up one line.
>>
>> That sounds a bit brittle -- I'm sure there'll be other extensions like
>> this in the future to the IMAP protocol.
>>
>>> I've configured my local Dovecot with the offending setting, and will
>>> test it out for a bit.
>>
>> Great!
>
> (NB This patch is very broken and no one should use it; I'm still
> working on it. I want a proper parser!)
Turns out the dumb thing was simple: I was testing if the FETCH line was
followed by mail headers by looking for:
"\\(From\\|To\\|Subject\\|Date\\|Message-ID\\)"
Which is obviously insufficient. I've since changed it to:
"\\([A-Z][[:ascii:]-]+: \\)"
Which works better, but also seems susceptible to breakage due to
ignorance. A quick scan doesn't turn up any `mail-header-regexp'
variables or `this-is-a-mail-header-p' functions -- does the above
regexp seem reasonable?