a bug with gnus-summary-refer-article?

a bug with gnus-summary-refer-article?

[Alan Schmitt]

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

Hello,

I think I found a bug with `gnus-summary-refer-article'. If I fetch an
article that comes from another group, it gets inserted in the summary
with a number of -1. During the call to `gnus-summary-mark-article', the
following is done

(setq mark (gnus-request-update-mark gnus-newsgroup-name article mark))

which results in mark being nil. This in turn makes the comparisons such
as

(= mark gnus-unread-mark)

fail with a "Wrong type argument: number-or-marker-p, nil".

Here is a trimmed-down backtrace:

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  =(nil 32)
  ...
  gnus-summary-mark-article(-1 82)
  gnus-summary-mark-read-and-unread-as-read()
  run-hooks(gnus-mark-article-hook)
  apply(run-hooks gnus-mark-article-hook)
  gnus-run-hooks(gnus-mark-article-hook)
  gnus-article-prepare(-1 nil)
  gnus-summary-display-article(-1 nil)
  gnus-summary-select-article(nil nil nil -1)
  (progn (gnus-summary-select-article nil nil nil number) (throw (quote found) t))
  ...
  gnus-summary-refer-article("52947012.308@cse.gu.se")
  call-interactively(gnus-summary-refer-article nil nil)
  command-execute(gnus-summary-refer-article)

Is this a known bug?

Thanks,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated December 28, 2015, Mauna Loa Obs.): 402.60 ppm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: a bug with gnus-summary-refer-article?

[Alan Schmitt]

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

Hello,

I reported this as a bug. Here is the link:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22353

Alan

On 2016-01-10 22:21, Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> Hello,
>
> I think I found a bug with `gnus-summary-refer-article'. If I fetch an
> article that comes from another group, it gets inserted in the summary
> with a number of -1. During the call to `gnus-summary-mark-article', the
> following is done
>
> (setq mark (gnus-request-update-mark gnus-newsgroup-name article mark))
>
> which results in mark being nil. This in turn makes the comparisons such
> as
>
> (= mark gnus-unread-mark)
>
> fail with a "Wrong type argument: number-or-marker-p, nil".
>
> Here is a trimmed-down backtrace:
>
> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>   =(nil 32)
>   ...
>   gnus-summary-mark-article(-1 82)
>   gnus-summary-mark-read-and-unread-as-read()
>   run-hooks(gnus-mark-article-hook)
>   apply(run-hooks gnus-mark-article-hook)
>   gnus-run-hooks(gnus-mark-article-hook)
>   gnus-article-prepare(-1 nil)
>   gnus-summary-display-article(-1 nil)
>   gnus-summary-select-article(nil nil nil -1)
>   (progn (gnus-summary-select-article nil nil nil number) (throw (quote found) t))
>   ...
>   gnus-summary-refer-article("52947012.308@cse.gu.se")
>   call-interactively(gnus-summary-refer-article nil nil)
>   command-execute(gnus-summary-refer-article)
>
> Is this a known bug?
>
> Thanks,
>
> Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated January 10, 2016, Mauna Loa Obs.): 402.22 ppm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: a bug with gnus-summary-refer-article?

[Katsumi Yamaoka]

On Sun, 10 Jan 2016 22:21:55 +0100, Alan Schmitt wrote:
> I think I found a bug with `gnus-summary-refer-article'. If I fetch an
> article that comes from another group, it gets inserted in the summary
> with a number of -1. During the call to `gnus-summary-mark-article', the
> following is done

> (setq mark (gnus-request-update-mark gnus-newsgroup-name article mark))

> which results in mark being nil.
[...]
> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>   =(nil 32)
>   gnus-summary-mark-article(-1 82)
[...]
>   gnus-summary-refer-article("52947012.308@cse.gu.se")

I'm not quite sure whether these are helpful questions, but

What is the method of the group (nnml, nnimap, ...) you are in?
What is the method of the group where <52947012.308@cse.gu.se> comes?
What is the mark the <52947012.308@cse.gu.se> article had?

I haven't been able to reproduce such an error so far.

Re: a bug with gnus-summary-refer-article?

[Alan Schmitt]

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

On 2016-01-13 09:50, Katsumi Yamaoka <yamaoka@jpl.org> writes:

> On Sun, 10 Jan 2016 22:21:55 +0100, Alan Schmitt wrote:
>> I think I found a bug with `gnus-summary-refer-article'. If I fetch an
>> article that comes from another group, it gets inserted in the summary
>> with a number of -1. During the call to `gnus-summary-mark-article', the
>> following is done
>
>> (setq mark (gnus-request-update-mark gnus-newsgroup-name article mark))
>
>> which results in mark being nil.
> [...]
>> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>>   =(nil 32)
>>   gnus-summary-mark-article(-1 82)
> [...]
>>   gnus-summary-refer-article("52947012.308@cse.gu.se")
>
> I'm not quite sure whether these are helpful questions, but
>
> What is the method of the group (nnml, nnimap, ...) you are in?

nnimap

> What is the method of the group where <52947012.308@cse.gu.se> comes?

nnimap, from another server

> What is the mark the <52947012.308@cse.gu.se> article had?

79, which seems to be 'O'.

> I haven't been able to reproduce such an error so far.

The crux of the error is on line 11110 of gnus-sem.el. When I edebug
this function, it is used twice (once for the existing article in the
group, and once for the newly inserted article). During the second
execution, this line

 (setq mark (gnus-request-update-mark gnus-newsgroup-name article mark))

evaluates to nil, I guess because `article' is a negative number or
because the article comes from a group that is on another server. Do you
see this as well?

Thanks,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated January 11, 2016, Mauna Loa Obs.): 401.96 ppm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: a bug with gnus-summary-refer-article?

[Katsumi Yamaoka]

On Wed, 13 Jan 2016 09:49:34 +0100, Alan Schmitt wrote:
> On 2016-01-13 09:50, Katsumi Yamaoka <yamaoka@jpl.org> writes:
[...]
>> What is the method of the group (nnml, nnimap, ...) you are in?

> nnimap

>> What is the method of the group where <52947012.308@cse.gu.se> comes?

> nnimap, from another server

>> What is the mark the <52947012.308@cse.gu.se> article had?

> 79, which seems to be 'O'.

I'm not a nnimap user much less a nnimap expert, sorry.  But...

> The crux of the error is on line 11110 of gnus-sem.el. When I edebug
> this function, it is used twice (once for the existing article in the
> group, and once for the newly inserted article). During the second
> execution, this line

>  (setq mark (gnus-request-update-mark gnus-newsgroup-name article mark))

> evaluates to nil, I guess because `article' is a negative number or
> because the article comes from a group that is on another server. Do you
> see this as well?

Ok, I'll try it with the other back end and different servers.

Re: a bug with gnus-summary-refer-article?

[Katsumi Yamaoka]

On Wed, 13 Jan 2016 18:10:04 +0900, Katsumi Yamaoka wrote:
> Ok, I'll try it with the other back end and different servers.

After having done some tests, I got to guess that it might arise
with only nnimap.  So, I'd like to ask nnimap people to reproduce
and fix it:

<http://thread.gmane.org/gmane.emacs.gnus.general/86583/focus=86599>

Thanks.
Regards,

Re: a bug with gnus-summary-refer-article?

[Alan Schmitt]

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

On 2016-01-13 18:30, Katsumi Yamaoka <yamaoka@jpl.org> writes:

> On Wed, 13 Jan 2016 18:10:04 +0900, Katsumi Yamaoka wrote:
>> Ok, I'll try it with the other back end and different servers.
>
> After having done some tests, I got to guess that it might arise
> with only nnimap.  So, I'd like to ask nnimap people to reproduce
> and fix it:
>
> <http://thread.gmane.org/gmane.emacs.gnus.general/86583/focus=86599>

Thank you for your tests.

After a little more debugging here, it seems that what happens is that
the following configuration is important for this to break:

(setq gnus-refer-article-method
      '(current
        (nnir "nnimap:inria")
        (nnir "nnimap:local")))

The `gnus-request-update-mark' function works well for nnimap (as there
is no corresponding function, so the initial mark is returned), but it
seems to be problematic with nnir. I cannot edebug it further because
`nnir-request-update-mark' is a deffoo, and I don’t know how to debug
those.

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated January 12, 2016, Mauna Loa Obs.): 401.82 ppm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: a bug with gnus-summary-refer-article?

[Alan Schmitt]

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

On 2016-01-13 11:33, Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> The `gnus-request-update-mark' function works well for nnimap (as there
> is no corresponding function, so the initial mark is returned), but it
> seems to be problematic with nnir. I cannot edebug it further because
> `nnir-request-update-mark' is a deffoo, and I don’t know how to debug
> those.

Using the lisp debugger I think I’ve found the crux of the problem, the
function `nnir-request-update-mark' from nnir.el returns nil when the
article number is negative. I see two way to solve the issue:

- return the original mark when the article is a negative number (which
  is basically what nnimap does)

The code would then be this:

#+begin_src emacs-lisp
(deffoo nnir-request-update-mark (group article mark)
  (let ((artgroup (nnir-article-group article))
	(artnumber (nnir-article-number article)))
    (if (and artgroup artnumber)
      (gnus-request-update-mark artgroup artnumber mark)
     mark)))
#+end_src

- allow the call to `gnus-request-update-mark' to return nil, but then
  protect the remainder of the code in that case

I’ll update the bug report with this information.

Thoughts?

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated January 12, 2016, Mauna Loa Obs.): 401.82 ppm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]