Re: Args out of range when quitting search buffer with recent Emacs/Gnus

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Adam Sjøgren <asjo@koldfront.dk> writes:

> Andrew writes:
>
>> OK, I had forgotten how nnml works :) I think you are likely right that
>> gnus can't figure out which backend to assign directories in the same
>> nnml tree. I guess the simplest thing to try is to move the archive
>> backend to an orthogonal directory tree.
>
> To start with, I tried just telling notmuch not to index anything in
> ~/Mail/archive.
>
> That way no results in there are ever returned.
>
> Interestingly, I can still get the error, if I search for something that
> generates a lot of hits, but not if I search for the thing that just
> generates two hits!
>
> So G G ejendomsvurderingen RET gives 2 hits, and I can q the search
> results.
>
> But G G USB ID RET gives 94 lines in the search results, and pressing q
> results in:
>
>   Args out of range: [["nnml:cvs" 1664 0] ["nnml:cvs" 1667 0] ["nnml:rt2400-devel" 74 0] ["nnml:rt2400-devel" 75 0] ["nnml:never-sent" 43 0] ["nnml:debian-bts" 225 0] ["nnml:debian-bts" 228 0] ["nnml:leif" 2036 0] ["nnml:cron" 6244 0] ["nnml:cron" 17494 0] ...], 999
>
> So I'm guessing the archive theory can be dismissed as the cause.
>
> Backtrace:
>
>   Debugger entered--Lisp error: (args-out-of-range [["nnml:cvs" 1664 0] ["nnml:cvs" 1667 0] ["nnml:rt2400-devel" 74 0] ["nnml:rt2400-devel" 75 0] ["nnml:never-sent" 43 0] ["nnml:debian-bts" 225 0] ["nnml:debian-bts" 228 0] ["nnml:leif" 2036 0] ["nnml:cron" 6244 0] ["nnml:cron" 17494 0] ["nnml:cron" 17793 0] ["nnml:cron" 18110 0] ["nnml:cron" 18294 0] ["nnml:cron" 18488 0] ["nnml:cron" 18638 0] ["nnml:cron" 18792 0] ["nnml:cron" 18990 0] ["nnml:cron" 19218 0] ["nnml:cron" 19423 0] ["nnml:cron" 19634 0] ["nnml:cron" 19812 0] ["nnml:cron" 19816 0] ["nnml:cron" 19817 0] ["nnml:cron" 19828 0] ["nnml:cron" 19829 0] ["nnml:cron" 19856 0] ["nnml:cron" 19933 0] ["nnml:cron" 19939 0] ["nnml:cron" 19943 0] ["nnml:cron" 19969 0] ["nnml:cron" 19977 0] ["nnml:cron" 20119 0] ["nnml:cron" 20268 0] ["nnml:cron" 20392 0] ["nnml:cron" 20476 0] ["nnml:cron" 20569 0] ["nnml:cron" 20671 0] ["nnml:cron" 20785 0] ["nnml:cron" 20978 0] ["nnml:cron" 21054 0] ["nnml:cron" 21870 0] ["nnml:cron" 21921 0] ["nnml:cron" 21964 0] ["nnml:cron" 22084 0] ["nnml:cron" 22305 0] ["nnml:cron" 22353 0] ["nnml:cron" 22425 0] ["nnml:cron" 23190 0] ["nnml:cron" 23247 0] ["nnml:cron" 23299 0] ...] 999)
>     nnselect-article-group(1000)
>     #f(compiled-function (member) #<bytecode 0x1867d85b70e9665d>)(1000)
>     mapc(#f(compiled-function (member) #<bytecode 0x1867d85b70e9665d>) (1000 999 998 997 996 995 994 993 992 991 990 989 988 987 986 985 984 983 982 981 980 979 978 977 976 975 974 973 972 971 970 969 968 967 966 965 964 963 962 961 960 959 958 957 956 955 954 953 952 951 ...))
>     nnselect-push-info("nnselect:nnselect-87k0wxhd6v.fsf")
>     nnselect-close-group("nnselect-87k0wxhd6v.fsf" "nnselect-ephemeral")
>     gnus-close-group("nnselect:nnselect-87k0wxhd6v.fsf")
>     gnus-summary-exit()
>     funcall-interactively(gnus-summary-exit)
>     call-interactively(gnus-summary-exit nil nil)
>     command-execute(gnus-summary-exit)
>
> There is something funky about those 1000, as you say.

Jumping in here quickly while Andy sorts out his computer...

I think the simplest next step would be to figure out which list of
marks thinks there are 1000 articles in this group. Is it always 1000,
no matter how many search results you get? I imagine we'll eventually
see why that's significant, but I can't think of anything now. My best
guess is that a list of marks that's meant to be local to the summary
buffer is somehow getting set and/or read globally.

Would you run a search that you're confident will trigger the error, and
evaluate this *in that buffer* (ie with "M-:" in the buffer).

(setq length-pairs
      (mapcar (lambda (mark-list)
		(cons mark-list
		      (length (symbol-value mark-list))))
	      (append (mapcar
		       (lambda (type)
			 (intern (format "gnus-newsgroup-%s" (car type))))
		       gnus-article-mark-lists)
		       '(gnus-newsgroup-unreads gnus-newsgroup-unseen))))

And then show us the (expanded) value of `length-pairs'?