Re: New nnimap error with Gcc

["Steven E. Harris" <seh@panix.com>]

Simon Josefsson <simon@josefsson.org> writes:

> For some reason, Gnus thinks the article number is nil instead of some
> integer.  I don't know why that happens.  Edebuging some of the
> functions named above might help.

gnus-request-accept-article calls on nnimap-request-accept-article
around line 620 in gnus-int.el. nnimap-request-accept-article returns
nil, because its last form is a call to nnheader-report, which always
returns nil.

This returned nil is captured in the "result" binding in
gnus-request-accept-article. The cdr of this nil value is then passed in
to gnus-agent-regenerate-group, where the nil result gets bound to the
optional "reread" argument. The nil value counts as a list on line 4071
in gnus-agent.el, so the nil is combined with 'del and '(read) and
passed on to gnus-agent-synchronize-group-flags, where it's bound to the
"actions" parameter.

This "actions" list makes it down to nnimap-request-set-mark, which
pulls apart each member into "range", "what", and "cmdmarks" around line
1245 in nnimap.el.

Given the "actions" list of

  (((nil) del (read)))

the car is

  ((nil) del (read))

of which (nth 0 *) yields

  (nil)

for the "range" binding. Down on line 1271 in nnimap.el, we test "range"
and find it non-nil, so we continue to try to pass it off to
imap-range-to-message-set, which fails.

I see a conflict here. There's an assumption that
nnimap-request-accept-article won't return nil, but I don't see how it
can return anything but nil, given that it returns with nnheader-report.

Does any of this help?

-- 
Steven E. Harris