GCC to Yahoo groups fails

[Eric S Fraga]

Hello,

A while back (months), GCC stopped working when sending email using my
yahoo account. GCC works with other IMAP servers, even Exchange acting
as IMAP, but not with Yahoo. Below is the stack trace on error:

,----
| Debugger entered--Lisp error: (wrong-type-argument stringp nil)
| string-match("^[^:]+:" nil)
| nnimap-retrieve-group-data-early("yahoo" (nil))
| nnimap-request-group("INBOX" "yahoo" t nil)
| gnus-request-group("nnimap+yahoo:INBOX" t (nnimap "yahoo" (nnimap-address "imap.mail.yahoo.com") (nnimap-server-port 993) (nnimap-stream ssl)))
| gnus-inews-do-gcc()
| gnus-agent-possibly-do-gcc()
| run-hooks(message-sent-hook)
| message-send(nil)
| message-send-and-exit(nil)
| funcall-interactively(message-send-and-exit nil)
| call-interactively(message-send-and-exit nil nil)
| command-execute(message-send-and-exit)
`----

Can anybody point at some configuration error I may have made? I
actually turn GCC off supposedly using "G c" on the group but that seems
to be ignored. Setting GCC in the group configuration to something
nnimap+yahoo:Folder (for any folder, e.g. INBOX in example above) also
fails: it's ignored and the GCC line always looks like
nnimap+yahoo:Sent.

I'm using gnus from git.

thanks,
eric

[Eric S Fraga]

Post by Eric S Fraga
A while back (months), GCC stopped working when sending email using my
yahoo account. GCC works with other IMAP servers, even Exchange acting

Partially answering my own email. I had gcc specified in the server
settings in my .gnus. I would have thought that the group parameters
would have overwritten the specifications in .gnus...

In any case, GCC works sometimes but not others, depending on the group
chosen to copy to. Inbox (not INBOX) works but Sent does not even
though the latter exists.

[Eric Abrahamsen]

Post by Eric S Fraga
Hello,
A while back (months), GCC stopped working when sending email using my
yahoo account. GCC works with other IMAP servers, even Exchange acting
,----
| Debugger entered--Lisp error: (wrong-type-argument stringp nil)
| string-match("^[^:]+:" nil)
| nnimap-retrieve-group-data-early("yahoo" (nil))
| nnimap-request-group("INBOX" "yahoo" t nil)
| gnus-request-group("nnimap+yahoo:INBOX" t (nnimap "yahoo" (nnimap-address "imap.mail.yahoo.com") (nnimap-server-port 993) (nnimap-stream ssl)))
| gnus-inews-do-gcc()
| gnus-agent-possibly-do-gcc()
| run-hooks(message-sent-hook)
| message-send(nil)
| message-send-and-exit(nil)
| funcall-interactively(message-send-and-exit nil)
| call-interactively(message-send-and-exit nil nil)
| command-execute(message-send-and-exit)
`----

This looks like an error we were discussing a bit earlier, related
nnmairix. The basic problem (as far as I can tell) is that after the
whole retrieve-group-data-early thing was added to Gnus,
`nnimap-request-group' fails if the optional "info" argument is nil.

At the time I wasn't sure what the best solution was: it seemed like
maybe the right solution was to always make sure new groups were
registered with Gnus. But your case demonstrates that nil "info"
arguments get passed in from other places in the codebase. And more
fundamentally, I'm realizing, if an argument is noted as &optional, we
should definitely treat it as optional!

If there are no objections, I'll push that change in the morning.

Eric

[Eric S Fraga]

On Friday, 4 Sep 2015 at 22:44, Eric Abrahamsen wrote:

[...]

Post by Eric Abrahamsen
This looks like an error we were discussing a bit earlier, related

Ah, I didn't follow the whole nnmairix discussion... :(

Post by Eric Abrahamsen
And more fundamentally, I'm realizing, if an argument is noted as
&optional, we should definitely treat it as optional!
If there are no objections, I'll push that change in the morning.

This sounds the way to go. No objection from me!

Thanks,
eric

[Eric Abrahamsen]

Post by Eric S Fraga
[...]

Post by Eric Abrahamsen
This looks like an error we were discussing a bit earlier, related

Ah, I didn't follow the whole nnmairix discussion... :(

No one's obliged to read all these confused threads :)

Post by Eric S Fraga

Post by Eric Abrahamsen
And more fundamentally, I'm realizing, if an argument is noted as
&optional, we should definitely treat it as optional!
If there are no objections, I'll push that change in the morning.

This sounds the way to go. No objection from me!

Done, see if this fixes your problem. I also had to fiddle with the
handling of the active parameter for new groups, I hope I did that
right. That shouldn't directly impact your situation, though.

E

[Eric S Fraga]

On Saturday, 5 Sep 2015 at 10:12, Eric Abrahamsen wrote:

[...]

Post by Eric Abrahamsen

Post by Eric S Fraga

Post by Eric Abrahamsen
And more fundamentally, I'm realizing, if an argument is noted as
&optional, we should definitely treat it as optional!
If there are no objections, I'll push that change in the morning.

This sounds the way to go. No objection from me!

Done, see if this fixes your problem. I also had to fiddle with the
handling of the active parameter for new groups, I hope I did that
right. That shouldn't directly impact your situation, though.
E

Seems to work. Many thanks!