From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28888 invoked from network); 13 Sep 2020 19:28:44 -0000 Received: from lists1.math.uh.edu (129.7.128.208) by inbox.vuxu.org with ESMTPUTF8; 13 Sep 2020 19:28:44 -0000 Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.94) (envelope-from ) id 1kHXfM-00Dp6s-AM; Sun, 13 Sep 2020 14:28:00 -0500 Received: from mx1.math.uh.edu ([129.7.128.32]) by lists1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kHXfH-00Dp4v-0n for ding@lists.math.uh.edu; Sun, 13 Sep 2020 14:27:55 -0500 Received: from quimby.gnus.org ([95.216.78.240]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kHXfF-00C8h4-33 for ding@lists.math.uh.edu; Sun, 13 Sep 2020 14:27:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=BxPL2eDF03XFY9PaUkmP3l4Mb15rX8GF2KJjSZfUjmI=; b=gcuJr9dCztgfkB90pD0A0E7jmd 14tnpJkNKYSBQ9TZdK0oX6oBzFl6DSoSeXbOm8VjdtA+sp0DQW/neCJ68kqckQ6QNfORTg35KnwYT wP7n8M8yqWVqdLnnb1q4TMtGotwczsIUboRYDTnewOH5bI+w3QFcWfOOFCoNFAc3E+Pw=; Received: from ericabrahamsen.net ([52.70.2.18] helo=mail.ericabrahamsen.net) by quimby with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kHXf7-0006pp-3k for ding@gnus.org; Sun, 13 Sep 2020 21:27:48 +0200 Received: from localhost (75-172-112-137.tukw.qwest.net [75.172.112.137]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id D4493FA095; Sun, 13 Sep 2020 19:27:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericabrahamsen.net; s=mail; t=1600025263; bh=BxPL2eDF03XFY9PaUkmP3l4Mb15rX8GF2KJjSZfUjmI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=EGexy0KOofqzgEzqfuTbAQVD/23jRP9qyGF7H9TBgiBKAx9PJM2nxN4Om7HLes5ro 6KAQghVjca4okr6iPm4XZ1R64tO3Cr8BB9XKn2ZZAgVmnBtJW2zGk1eVXnRc26WTMT 32JBnm5nsKmZC3yuWso5Ry8K7PpDQ4FBbF8FrDng= From: Eric Abrahamsen To: Adam =?utf-8?Q?Sj=C3=B8gren?= Cc: ding@gnus.org Subject: Re: Args out of range when quitting search buffer with recent Emacs/Gnus References: <87a6xug73j.fsf@tullinup.koldfront.dk> <87ft7lq23s.fsf@ust.hk> <871rj5es8v.fsf@tullinup.koldfront.dk> <87tuw1oka8.fsf@ust.hk> <87r1r5db4n.fsf@tullinup.koldfront.dk> <87o8m9oj1f.fsf@ust.hk> <874ko169b8.fsf@tullinup.koldfront.dk> <87k0wxoeu0.fsf@ust.hk> <87imchhcyz.fsf@tullinup.koldfront.dk> Date: Sun, 13 Sep 2020 12:27:40 -0700 In-Reply-To: <87imchhcyz.fsf@tullinup.koldfront.dk> ("Adam =?utf-8?Q?Sj?= =?utf-8?Q?=C3=B8gren=22's?= message of "Sun, 13 Sep 2020 18:13:08 +0200") Message-ID: <87imchscib.fsf@ericabrahamsen.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-ID: Precedence: bulk Adam Sj=C3=B8gren 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:rt24= 00-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:cr= on" 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" 198= 12 0] ["nnml:cron" 19816 0] ["nnml:cron" 19817 0] ["nnml:cron" 19828 0] ["n= nml: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:c= ron" 20476 0] ["nnml:cron" 20569 0] ["nnml:cron" 20671 0] ["nnml:cron" 2078= 5 0] ["nnml:cron" 20978 0] ["nnml:cron" 21054 0] ["nnml:cron" 21870 0] ["nn= ml: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) #)(1000) > mapc(#f(compiled-function (member) #) (1= 000 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 96= 3 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'?