From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Greg Klanderman Newsgroups: gmane.emacs.devel Subject: gnus-server-to-method crash on virtual server name in gnus-secondary-select-methods Date: Thu, 7 Jan 2021 13:14:18 -0500 Message-ID: <24567.20346.37031.450073@lwm.klanderman.net> Reply-To: Greg Klanderman Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="913"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jan 07 19:18:10 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kxZrO-00007l-He for ged-emacs-devel@m.gmane-mx.org; Thu, 07 Jan 2021 19:18:10 +0100 Original-Received: from localhost ([::1]:37314 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxZrN-0000J0-Ir for ged-emacs-devel@m.gmane-mx.org; Thu, 07 Jan 2021 13:18:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47434) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxZnm-0006li-4K for emacs-devel@gnu.org; Thu, 07 Jan 2021 13:14:26 -0500 Original-Received: from so254-31.mailgun.net ([198.61.254.31]:21450) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kxZnj-0000l9-Rj for emacs-devel@gnu.org; Thu, 07 Jan 2021 13:14:25 -0500 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=klanderman.net; q=dns/txt; s=mg; t=1610043263; h=Reply-To: Subject: To: From: Date: Message-ID: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=ARmU4EjAtZslQomkDblWIL3BT/b//O3kFuTnbj1H24k=; b=UKknqTNAft3e+uNpc4OTotwjIrxATCZw3zJMjuvcDuvGbfhjId32CNzjH4B0zACVDP8B2GEy JNJcwtuh/lDzMVqdV/pg3FQwY4u4t0r8kLXfHsBIO/wY2Fjk4xAPuuR80WXlMaZyg3XAjfLh Lrk7NzrHu1icxYg3jYlE5lgkVO8= X-Mailgun-Sending-Ip: 198.61.254.31 X-Mailgun-Sid: WyI5OTUyZSIsICJlbWFjcy1kZXZlbEBnbnUub3JnIiwgIjk3ZGJkOCJd Original-Received: from smtp2.klanderman.net (smtp2.klanderman.net [142.93.10.110]) by smtp-out-n09.prod.us-east-1.postgun.com with SMTP id 5ff74f7a9f9cd52344b16153 (version=TLS1.3, cipher=TLS_AES_128_GCM_SHA256); Thu, 07 Jan 2021 18:14:18 GMT Original-Received: from lwm.klanderman.net (pool-72-93-77-73.bstnma.fios.verizon.net [72.93.77.73]) by smtp2.klanderman.net (Postfix) with ESMTPSA id 72202417C5; Thu, 7 Jan 2021 13:14:18 -0500 (EST) Original-Received: by lwm.klanderman.net (Postfix, from userid 1000) id 2026529E3C76; Thu, 7 Jan 2021 13:14:18 -0500 (EST) X-Mailer: VM 8.0.12-devo-585 under 21.4 (patch 24) "Standard C" XEmacs Lucid (x86_64-linux-gnu) Received-SPF: pass client-ip=198.61.254.31; envelope-from=bounce+ffeceb.97dbd8-emacs-devel=gnu.org@klanderman.net; helo=so254-31.mailgun.net X-Spam_score_int: -7 X-Spam_score: -0.8 X-Spam_bar: / X-Spam_report: (-0.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 07 Jan 2021 13:16:33 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:262701 Archived-At: Hi, hopefully this is the correct list for reporting Gnus problems these days; I see there is also info-gnus-english@ but it doesn't look terribly active. Not subscribed so please include me in replies. I'm a long time Gnus user since early/mid 90's, and was fairly active reporting problems back then (still listed in 'Contributors'!). I have recently transitioned my email from nnfolder to nnmaildir as I ran up against 1Gb group file size limit (still on XEmacs 21.4 and Gnus 5.10.8). [As an aside, it took me some time to realize that I could not just incrementally transition my largest groups; it would appear that you can only have new mail delivered to a single server (get-new-mail=t) when splitting with Gnus. If that is still the case with current development version, it would be really nice to explain that somewhere in the manual. I did look at the current manual online https://www.gnu.org/software/emacs/manual/html_node/gnus/index.html and didn't see this covered. I had expected that nnmail-split-fancy would be able to just deliver to multiple backends/servers, either using the explicit "backend+name:group" form, or that it would look up the server based on the group name and deliver properly. But it seems that there is a loop over servers in gnus-secondary-select-methods, and whichever appears first and allows getting new mail gets all the new mail.] Anyway, in the process of this transition, I found that when I put my new nnmaildir server, named "mail" before '(nnfolder "") in gnus-secondary-select-methods, it crashes on startup in gnus-server-to-method. Since that code looks the same in emacs 21.7 / Gnus 5.13 it seemed warranted to report the issue. In detail: I still have some legacy nnfolder groups (old groups that are no longer delivered to). On startup, gnus-read-active-file loops over gnus-secondary-select-methods, and when the nnfolder appears second, Gnus has not yet opened the nnfolder server when gnus-read-active-file-1 is (first) called with the nnmaildir and loops over infos, calling gnus-find-method-for-group, in turn calling gnus-server-to-method for one of the nnfolder groups (gnus-server-to-method is called with "nnfolder:"). In that function, this code (unchanged in 5.13 / Debian testing emacs-gtk): ;; It could be a named method, search all servers (let ((servers gnus-secondary-select-methods)) (while (and servers (not (equal server (format "%s:%s" (caar servers) (cadar servers))))) (pop servers)) (car servers)) is not handling the fact that gnus-secondary-select-methods may contain virtual server name strings (only handling select methods, assuming it can take car/cdr of elements). For now I can just swap the order in gnus-secondary-select-methods so that the nnfolder is opened first but someday I'll transition to GNU emacs and newer Gnus so hopefully you can address this. [As a second aside, can you explain this code in gnus-summary-move-article (logically unchanged in current 5.13): ;; See whether the article is to be put in the cache. (let* ((expirable (gnus-group-auto-expirable-p to-group)) (marks (if expirable gnus-article-mark-lists (delete '(expirable . expire) (copy-sequence gnus-article-mark-lists)))) ..)..) It was unexpected that when I moved (B m) my mail to the new nnmaildir backend groups, articles marked expirable lost that mark, leaving them merely read. Is the condition in the 'if' there maybe reversed? I could maybe imagine that when moving to an auto-expirable group you might want to clear expirable on a move, assuming it will eventually be marked expirable again, automatically. IMO moving articles should preserve expirable like any other mark. I'd also love it if nnmail-expiry-wait were measured relative to when I mark an article expirable, is there any way to get that behavior in newer Gnus?] Thank you for so many decades of great work on Gnus! Greg