Re: Misbehaving gnus-gcc-mark-as-read while archiving to current group

[Carlos Pita <carlosjosepita@gmail.com>]

Hi,

thank you for your detailed answer, Emanuel.

Since then I've been exploring the issue from time to time, a bit
overwhelmed by the magnitude of gnus code, and I do think there is a
bug, indeed.

The problem is that gnus-summary-insert-new-articles assumes every new
active article to be unread:

      (setq gnus-newsgroup-unreads
        (gnus-sorted-nunion gnus-newsgroup-unreads new))

It seems like a sensible assumption, doesn't it? But sadly it's wrong in
this case, because the sent mail is meant to be already read. It will be
wrong in other cases too, since a "new" message coming from the imap
server, which could be simultaneously accessed by more than one client,
is not necessarily unread.

So currently you have 3 levels of inconsistency:

1) The imap server and M-g "think" the email is read.
2) /N "thinks" the email is unread.
3) The summary buffer (before /N or M-g) "thinks" there is no email.

I believe there is a very easy way to reduce these inconsistencies to
only:

1) The imap server, M-g, /N "think" the email is read.
2) The summary buffer (before /N or M-g) "thinks" there is no email.

Then you can just say that the summary buffer isn't immediately
refreshed, which doesn't feel so bad and is easier to understand and
live with.

Notice that gnus-summary-insert-new-articles is calling
gnus-summary-insert-articles, which already calculates the unread list
using gnus-list-of-unread-articles. So it seems to me that removing the
problematic union operation quoted above would be safe since
gnus-summary-insert-articles is already taking care of that.

I've reported this as a bug a number of days ago, and I would like to
add the above remark as a followup or commentary to the report, but I'm
not able to find instructions on how to do that.

Cheers
--
Carlos