[Top][All Lists]

[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 <address@hidden> writes:

> On 06/23/19 14:23 PM, Lars Ingebrigtsen wrote:
>> Eric Abrahamsen <address@hidden> 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:


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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]