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

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

[Carlos Pita]

Hi all,

in order to get a "conversation view" a la gmail I've configured gnus as
follows:


(setq gnus-gcc-mark-as-read t)
(setq gnus-message-archive-group
      (lambda (g)
	(unless (string-match ":" g)
	  (concat "nnimap+gmail:" g))))


nnimap+gmail is my primary method so I check for lacking of ":" in the
group name (only groups for secondary methods contain a ":", at least in
my case). The generated gcc header is correct: say the group is
"micro2", the gcc will be "nnimap+gmail:micro2". That's fine.

But then there are a lot of quirks I'm not sure what to do about. Say I
reply a message in "micro2" group. My reply is indeed archived to
"micro2" but in the summaries buffer:

1. At first the sent reply is not shown at all.
2. If I press /N, then the reply is shown but as unread.
3. If I press M-g, then the reply is shown read.

In the imap server the behavior is as expected: the reply appears inside
the "micro2" folder and it's marked read. The problem is obviously with
the refreshing of the gnus views/state itself.

Is this a bug? In any case, it seems a very misleading behavior to me.

Cheers
--
Carlos

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

[Emanuel Berg]

Carlos Pita <carlosjosepita@gmail.com> writes:

> ... But then there are a lot of quirks I'm not sure
> what to do about. Say I reply a message in "micro2"
> group. My reply is indeed archived to "micro2"...

I don't use exactly your setup - I have:

(setq gnus-gcc-mark-as-read t)
(setq gnus-message-archive-group '("nnml:mail.sent"))

> ... but in the summaries buffer:
> 1. At first the sent reply is not shown at all.

Did you enter the archive group from the group buffer
or did you just change buffer to the summary buffer
like between any other pair buffers? If you just
changed buffer to the summary, it'll be the same
summary as you left it.

> 2. If I press /N, then the reply is shown

Yes, that makes sense:
gnus-summary-insert-new-articles to refresh/update.

> but as unread.

What mark do they have? Mine has `O', which reads:

    Articles that were marked as read in previous
    sessions and are now "old" (`gnus-ancient-mark').

I.e., technically, they are "read".

> 3. If I press M-g, then the reply is shown read.

Yes, M-g is gnus-summary-rescan-group which ends with
gnus-summary-select-article if you check out the code.
So, M-g doesn't change the mark of the post per se - it
shows the posts, so the mark gets changed along the way.

> Is this a bug? In any case, it seems a very
> misleading behavior to me.

I don't think it is a bug, it is rather Gnus can be all
over the place sometimes. What happens at place A
doesn't show at place B because B is just a buffer
showing stuff and less no one tells it it should
refresh it doesn't. I myself haven't found a good way
to consistently have everything in synch - do tell, if
anyone knows. Everything that changes the state should
trigger the refresh of all Gnus buffers, I think.

I have lots of glue to achieve an imperfect
implementation of that idea, e.g., when you exit from a
summary buffer, whatever you did there should be
visible in the Group buffer - this wouldn't do with
hooks so I wrote:

(defun gnus-summary-exit-and-update-group ()
  (interactive)
  (gnus-summary-save-newsrc t) ; FORCE
  (kill-buffer)
  (gnus-group-refresh) )

where the last line does that for my configuration (it
is not a standard Gnus function).

But even that isn't good as the ultimate would be
"global Gnus" + newsrc file consistency immediately on
the change of mark for a single post. That I'd like -
everywhere!
  
-- 
underground experts united

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

[Carlos Pita]

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

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

[Emanuel Berg]

Carlos Pita <carlosjosepita@gmail.com> writes:

> 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.

The summary buffer isn't refreshed automatically if it
is open and then you do something in the group buffer
that should show in the summary buffer. That's just a
general observation. If you don't have a summary
buffer, and it shows up, but the marks are
inconsistent, then that is either a misunderstanding, a
misconfiguration, or a bug - or a combination :) The
rule of bug reports is, though, that if you think or
suspect it is a bug, you should report it! Sometimes it
isn't a bug, but that's OK.

> 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.

Good question. There are bug tracking systems where you
can provide additional information - as in, the bug is
a Usenet thread itself, somewhat - but I don't know
what Gnus uses. Since the discussion on gnu.emacs.gnus
is ultra-on-topic (which is great), I assume that the
developers read every single line, so I don't think you
have to worry that this post of yours is lost to them.

-- 
underground experts united

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

[Carlos Pita]

> 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.

Ok, I finally found out how to do this. The automatic ack that is send
just after reporting a bug contains instructions (the usual debbugs
ones) to submit further information: just send an email to
NNNNN@debbugs.gnu.org, where NNNNN is the bug number (also reported in
the ack email).

I've deleted the ack the first time so I was clueless after that.

Cheers
--
Carlos

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

[Emanuel Berg]

Carlos Pita <carlosjosepita@gmail.com> writes:

>> 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.
>
> Ok, I finally found out how to do this. The automatic
> ack that is send just after reporting a bug contains
> instructions (the usual debbugs ones) to submit
> further information: just send an email to
> NNNNN@debbugs.gnu.org, where NNNNN is the bug number
> (also reported in the ack email).

Cool!

> I've deleted the ack the first time so I was clueless
> after that.

Well, let this be a life lesson... No, kidding, but
yeah, it is a good idea to always save all your
correspondence. That is one thing I like with Gnus, it
doesn't show old stuff, but when you need it, it is
still there.

-- 
underground experts united