nnimap: gnus-gcc-mark-as-read not working

nnimap: gnus-gcc-mark-as-read not working

[Wolfram Fenske]

Hello!

I have sent mail Gcc-ed to a folder on my IMAP-server.  This mostly
works, but the copy in the sent-mail folder is never marked as read.
In my .gnus.el I have:

--8<---------------cut here---------------start------------->8---
(setq gnus-message-archive-group  "nnimap+uni:INBOX.sent-mail"
      gnus-gcc-mark-as-read       t)
--8<---------------cut here---------------end--------------->8---

If I use nnfolder for archiving, i. e. if I set
`gnus-message-archive-group' to "sent-mail", and leave everything else
untouched, archiving works as it should.  Am I missing something or is
this an nnimap bug?  Does anybody else have this problem?


Regards
Wolfram

Re: nnimap: gnus-gcc-mark-as-read not working

[Wolfram Fenske]

[-- Attachment #1: Type: text/plain, Size: 1973 bytes --]

Wolfram Fenske <Wolfram.Fenske@Student.Uni-Magdeburg.DE> writes:

> Hello!
>
> I have sent mail Gcc-ed to a folder on my IMAP-server.  This mostly
> works, but the copy in the sent-mail folder is never marked as read.
> In my .gnus.el I have:
>
> --8<---------------cut here---------------start------------->8---
> (setq gnus-message-archive-group  "nnimap+uni:INBOX.sent-mail"
>       gnus-gcc-mark-as-read       t)
> --8<---------------cut here---------------end--------------->8---
>
> If I use nnfolder [...], archiving works as it should.

I've tracked it down.  The error occurs here:

--8<---------------cut here---------------start------------->8---
(defun gnus-group-make-articles-read (group articles)
  "Update the info of GROUP to say that ARTICLES are read."
  (let* ((num 0)
	 (entry (gnus-gethash group gnus-newsrc-hashtb))
    ... ; some more initializing
    (when entry
      ... ; do all the work
--8<---------------cut here---------------end--------------->8---

For my IMAP sent-mail group, "entry" is always "nil" because "group"
is "nnimap+uni:INBOX.sent-mail" but my ~/.newsrc.eld contains only
entries like "INBOX.sent-mail", i. e. the prefix "nnimap+uni:" is
missing.

Now the question is: why don't I have the prefixes in ~/.newsrc.eld?
Is this because nnimap is my primary gnus-select-method?  A while back
I had nnimap as my secondary select method and I think I didn't have
this problem then.

Also: is there a bug in "gnus-group-make-articles-read" or is it my
config?  I tought

--8<---------------cut here---------------start------------->8---
(setq gnus-message-archive-method '(nnimap "my.imap.server.de")
      gnus-message-archive-group  "INBOX.sent-mail")
--8<---------------cut here---------------end--------------->8---

might do the trick, but this didn't fix it, either.

If there really is a bug, and someone can tell me what's going on with
those prefixes, I'd be happy to write a patch.  Until then, I'm using
this workaround:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: make-articles-read.patch --]
[-- Type: text/x-patch, Size: 580 bytes --]

*** gnus-sum.el.orig	Fri Apr 14 08:01:20 2006
--- gnus-sum.el	Fri Apr 14 10:04:05 2006
***************
*** 5744,5749 ****
--- 5744,5754 ----
    "Update the info of GROUP to say that ARTICLES are read."
    (let* ((num 0)
  	 (entry (gnus-gethash group gnus-newsrc-hashtb))
+ 	 (entry (or entry
+ 		    ;; strip the backend prefix and try again
+ 		    (when (string-match "\\([^+]+\\+[^:]+:\\)?\\(.+\\)" group)
+ 		      (setq group (match-string 2 group))
+ 		      (gnus-gethash group gnus-newsrc-hashtb))))
  	 (info (nth 2 entry))
  	 (active (gnus-active group))
  	 range)

[-- Attachment #3: Type: text/plain, Size: 147 bytes --]



Regards
Wolfram

-- 
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?

Re: nnimap: gnus-gcc-mark-as-read not working

[Dave Goldberg]

>>>>> On Fri, 14 Apr 2006 01:55:27 +0200, Wolfram Fenske <Wolfram.Fenske@Student.Uni-Magdeburg.DE> said:

> Hello!

> I have sent mail Gcc-ed to a folder on my IMAP-server.  This mostly
> works, but the copy in the sent-mail folder is never marked as read.
> In my .gnus.el I have:


> (setq gnus-message-archive-group  "nnimap+uni:INBOX.sent-mail"
>       gnus-gcc-mark-as-read       t)


> If I use nnfolder for archiving, i. e. if I set
> `gnus-message-archive-group' to "sent-mail", and leave everything else
> untouched, archiving works as it should.  Am I missing something or is
> this an nnimap bug?  Does anybody else have this problem?

Maybe it's fixed in CVS?  I use No Gnus and it works fine for me.  I
note though that i use explicit Gcc headers set by posting-styles
rather than gnus-message-archive-group.

-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: nnimap: gnus-gcc-mark-as-read not working

[Simon Josefsson]

Wolfram Fenske <Wolfram.Fenske@Student.Uni-Magdeburg.DE> writes:

> Wolfram Fenske <Wolfram.Fenske@Student.Uni-Magdeburg.DE> writes:
>
>> Hello!
>>
>> I have sent mail Gcc-ed to a folder on my IMAP-server.  This mostly
>> works, but the copy in the sent-mail folder is never marked as read.
>> In my .gnus.el I have:
>>
>> --8<---------------cut here---------------start------------->8---
>> (setq gnus-message-archive-group  "nnimap+uni:INBOX.sent-mail"
>>       gnus-gcc-mark-as-read       t)
>> --8<---------------cut here---------------end--------------->8---
>>
>> If I use nnfolder [...], archiving works as it should.
>
> I've tracked it down.  The error occurs here:
>
> (defun gnus-group-make-articles-read (group articles)
>   "Update the info of GROUP to say that ARTICLES are read."
>   (let* ((num 0)
> 	 (entry (gnus-gethash group gnus-newsrc-hashtb))
>     ... ; some more initializing
>     (when entry
>       ... ; do all the work
>
> For my IMAP sent-mail group, "entry" is always "nil" because "group"
> is "nnimap+uni:INBOX.sent-mail" but my ~/.newsrc.eld contains only
> entries like "INBOX.sent-mail", i. e. the prefix "nnimap+uni:" is
> missing.

Doesn't it work to simply drop the 'nnimap+uni:' part above?

> Now the question is: why don't I have the prefixes in ~/.newsrc.eld?
> Is this because nnimap is my primary gnus-select-method?  A while back
> I had nnimap as my secondary select method and I think I didn't have
> this problem then.
>
> Also: is there a bug in "gnus-group-make-articles-read" or is it my
> config?  I tought
>
> (setq gnus-message-archive-method '(nnimap "my.imap.server.de")
>       gnus-message-archive-group  "INBOX.sent-mail")
>
> might do the trick, but this didn't fix it, either.
>
> If there really is a bug, and someone can tell me what's going on with
> those prefixes, I'd be happy to write a patch.  Until then, I'm using
> this workaround:

I've found that the easiest is to use a nnnil method as the primary
method, and then have all methods being equal.


> *** gnus-sum.el.orig	Fri Apr 14 08:01:20 2006
> --- gnus-sum.el	Fri Apr 14 10:04:05 2006
> ***************
> *** 5744,5749 ****
> --- 5744,5754 ----
>     "Update the info of GROUP to say that ARTICLES are read."
>     (let* ((num 0)
>   	 (entry (gnus-gethash group gnus-newsrc-hashtb))
> + 	 (entry (or entry
> + 		    ;; strip the backend prefix and try again
> + 		    (when (string-match "\\([^+]+\\+[^:]+:\\)?\\(.+\\)" group)
> + 		      (setq group (match-string 2 group))
> + 		      (gnus-gethash group gnus-newsrc-hashtb))))
>   	 (info (nth 2 entry))
>   	 (active (gnus-active group))
>   	 range)
>
>
> Regards
> Wolfram
>
> -- 
> A: Yes.
>>Q: Are you sure?
>>>A: Because it reverses the logical flow of conversation.
>>>>Q: Why is top posting frowned upon?

Bug in gnus-group-make-articles-read? (was: nnimap: gnus-gcc-mark-as-read not working)

[Wolfram Fenske]

Simon Josefsson <jas@extundo.com> writes:

> Wolfram Fenske <Wolfram.Fenske@Student.Uni-Magdeburg.DE> writes:
>
>> Wolfram Fenske <Wolfram.Fenske@Student.Uni-Magdeburg.DE> writes:
>>
>>> I have sent mail Gcc-ed to a folder on my IMAP-server.  This mostly
>>> works, but the copy in the sent-mail folder is never marked as read.
>>> In my .gnus.el I have:
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> (setq gnus-message-archive-group  "nnimap+uni:INBOX.sent-mail"
>>>       gnus-gcc-mark-as-read       t)
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> If I use nnfolder [...], archiving works as it should.
>>
>> [...]
>>
>> For my IMAP sent-mail group, "entry" is always "nil" because "group"
>> is "nnimap+uni:INBOX.sent-mail" but my ~/.newsrc.eld contains only
>> entries like "INBOX.sent-mail", i. e. the prefix "nnimap+uni:" is
>> missing.
>
> Doesn't it work to simply drop the 'nnimap+uni:' part above?

Unfortunately, it doesn't, I just checked again (I knew I had tried
this at some point ...).  If I omit it, gnus adds the prefix
"nnfolder+archive:", so I get a header field saying

--8<---------------cut here---------------start------------->8---
Gcc: nnfolder+archive:INBOX.sent-mail
--8<---------------cut here---------------end--------------->8---

I have to admit, I cheated a bit before.  Actually, my setup is

--8<---------------cut here---------------start------------->8---
(setq gnus-message-archive-group '("nnimap+uni:INBOX.sent-mail" "sent-mail"))
--8<---------------cut here---------------end--------------->8---

I should have said that before.  

Anyway, from reading the docs, I got the impression these setting were
a correct way to accomplish creating both a carbon copy on the IMAP
server and one in a local folder.  My logic was: use the full name to
make it clear I mean the nnimap group and use an "unqualified" name
for the local copy, which gnus auto-completes using the value of
"gnus-message-archive-method" (I don't set this variable myself.).

>> Now the question is: why don't I have the prefixes in ~/.newsrc.eld?
>> Is this because nnimap is my primary gnus-select-method?  A while back
>> I had nnimap as my secondary select method and I think I didn't have
>> this problem then.
>>
>> Also: is there a bug in "gnus-group-make-articles-read" or is it my
>> config?  [...]
>
> I've found that the easiest is to use a nnnil method as the primary
> method, and then have all methods being equal.

That sounds like the way to go [1].  Still, I wonder whether the
behavior I described constitutes a bug or not.  I'm thinking, yes, but
I don't know enough about the internals of gnus to actually decide
that.


Greetings
Wolfram

Footnotes: 
[1]  Maybe the distinction between primary method and secondary
methods should be removed altogether.  I suppose it was good for
backward compatibility back in the day but now it's only asymmetric,
and it appears to me that the problem I described in this thread stems
from this very asymmetry.  Why else would my IMAP groups (primary
method) be called e. g. "INBOX.sent-mail" in my ~/.newsrc.eld file,
when groups from other backends (secondary methods) are called
"nnfolder+archive:sent-mail" etc.?  I'm almost sure, if it wasn't for
the different naming schemes, I wouldn't have had the problem.

-- 
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?

Re: nnimap: gnus-gcc-mark-as-read not working

[Wolfram Fenske]

Simon Josefsson <jas@extundo.com> writes:

> Wolfram Fenske <Wolfram.Fenske@Student.Uni-Magdeburg.DE> writes:
>
>> Wolfram Fenske <Wolfram.Fenske@Student.Uni-Magdeburg.DE> writes:
>>
>>> I have sent mail Gcc-ed to a folder on my IMAP-server.  This mostly
>>> works, but the copy in the sent-mail folder is never marked as read.
>>> In my .gnus.el I have:
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> (setq gnus-message-archive-group  "nnimap+uni:INBOX.sent-mail"
>>>       gnus-gcc-mark-as-read       t)
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> If I use nnfolder [...], archiving works as it should.
>>
>> [...]
>>
>> For my IMAP sent-mail group, "entry" is always "nil" because "group"
>> is "nnimap+uni:INBOX.sent-mail" but my ~/.newsrc.eld contains only
>> entries like "INBOX.sent-mail", i. e. the prefix "nnimap+uni:" is
>> missing.
>
> Doesn't it work to simply drop the 'nnimap+uni:' part above?

Unfortunately, it doesn't, I just checked again (I knew I had tried
this at some point ...).  If I omit it, gnus adds the prefix
"nnfolder+archive:", so I get a header field saying

--8<---------------cut here---------------start------------->8---
Gcc: nnfolder+archive:INBOX.sent-mail
--8<---------------cut here---------------end--------------->8---

I have to admit, I cheated a bit before.  Actually, my setup is

--8<---------------cut here---------------start------------->8---
(setq gnus-message-archive-group '("nnimap+uni:INBOX.sent-mail" "sent-mail"))
--8<---------------cut here---------------end--------------->8---

I should have said that before.  

Anyway, from reading the docs, I got the impression these setting were
a correct way to accomplish creating both a carbon copy on the IMAP
server and one in a local folder.  My logic was: use the full name to
make it clear I mean the nnimap group and use an "unqualified" name
for the local copy, which gnus auto-completes using the value of
"gnus-message-archive-method" (I don't set this variable myself.).

>> Now the question is: why don't I have the prefixes in ~/.newsrc.eld?
>> Is this because nnimap is my primary gnus-select-method?  A while back
>> I had nnimap as my secondary select method and I think I didn't have
>> this problem then.
>>
>> Also: is there a bug in "gnus-group-make-articles-read" or is it my
>> config?  [...]
>
> I've found that the easiest is to use a nnnil method as the primary
> method, and then have all methods being equal.

That sounds like the way to go [1].  Still, I wonder whether the
behavior I described constitutes a bug or not.  I'm thinking, yes, but
I don't know enough about the internals of gnus to actually decide
that.


Greetings
Wolfram

Footnotes: 
[1]  Maybe the distinction between primary method and secondary
methods should be removed altogether.  I suppose it was added for
backward compatibility back in the day but now it's only asymmetric,
and it appears to me that the problem I described in this thread stems
from this very asymmetry.  Why else would my IMAP groups (primary
method) be called e. g. "INBOX.sent-mail" in my ~/.newsrc.eld file,
when groups from other backends (secondary methods) are called
"nnfolder+archive:sent-mail" etc.?  I'm sure, if it wasn't for the
different naming schemes, I wouldn't have had the problem.

-- 
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?