From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Semyonov Newsgroups: gmane.emacs.devel Subject: Re: master 1601c5a518d: Gnus: Add back end for Atom feeds (nnatom) Date: Tue, 30 Apr 2024 00:02:22 +0300 Message-ID: <874jbj6fxd.fsf@dsemy.com> References: <171389641522.15334.4055859790974801392@vcs2.savannah.gnu.org> <20240423182018.97FA3C12C33@vcs2.savannah.gnu.org> <87a5ldn4fu.fsf@gmx.de> <871q6p2z5r.fsf@ericabrahamsen.net> <8734r5avt6.fsf@ericabrahamsen.net> <877cggjf2q.fsf@gmx.de> <70BFC2F4-E3F5-4515-9FEE-F293BDE1D3D3@gmail.com> <87a5lc57zn.fsf@dsemy.com> <87sez49bco.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24724"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= , Michael Albinus , emacs-devel@gnu.org To: Eric Abrahamsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 29 23:04:33 2024 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 1s1YAq-00068l-LY for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Apr 2024 23:04:33 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s1YA9-0006KW-15; Mon, 29 Apr 2024 17:03:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s1YA7-0006KJ-2s for emacs-devel@gnu.org; Mon, 29 Apr 2024 17:03:47 -0400 Original-Received: from dsemy.com ([46.23.89.208]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s1YA4-0007Cd-Rp for emacs-devel@gnu.org; Mon, 29 Apr 2024 17:03:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=dkim; bh=Tzd+m6M/o2h8n Ax9CVy37mVtLbV8w75XZKOerFkSKwU=; h=date:references:in-reply-to: subject:cc:to:from; d=dsemy.com; b=Edzsb9x+ZR/Iu1st5TLxa/9QU3/zdzW59O6 80yfqSvQmfBf91thPG6Xls2KoHKOp0BWcB8l8Pke3X5dRagJh34IehW9HdHON5I8bax/Si 8vxFZAJCqAcJlObirVvxwF8FC+zhL4lfi3ANUaW2Alzy8gakuHc2bpccEEfZZzrxMmSeig ea+ULaIO65qtiEKONZayobw8Kk/0CYmH0j0EJQp/ytMOwUwvykIVSSbLUSkr7uF9QCWx5a BBwUvIYJxMMkLb9WlU0WY8ZLVTThH1TX4BQvhWgCK9toRySE70DII77GgJADVgFcwcoic5 nwAEneltxqDyFpEN4C+ZqggnXEQ== Original-Received: from coldharbour.local ( [2a06:c701:4864:6500:8193:ebb0:ffbc:2f3b]) by dsemy.com (OpenSMTPD) with ESMTPSA id 7fe9bdad (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 29 Apr 2024 23:03:42 +0200 (CEST) Original-Received: from localhost (coldharbour.local [local]) by coldharbour.local (OpenSMTPD) with ESMTPA id ea1d1379; Mon, 29 Apr 2024 21:02:22 +0000 (UTC) In-Reply-To: <87sez49bco.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Mon, 29 Apr 2024 13:12:55 -0700") Received-SPF: pass client-ip=46.23.89.208; envelope-from=daniel@dsemy.com; helo=dsemy.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:318386 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable >>>>> Eric Abrahamsen writes: > On 04/29/24 21:39 PM, Daniel Semyonov wrote: >>>>>>> Mattias Engdeg=C3=A5rd writes: >>=20 >> > 29 apr. 2024 kl. 18.42 skrev Michael Albinus : >> >> Eric Abrahamsen writes: >> >>=20 >> >>> This is still failing the tests, and I can't see why, I suspect = the >> >>> reason is in the "... ..." below: >>=20 >> > No, you should ignore that and look at the text >>=20 >> >> The following options might have problems: >> >> variable: gnus-valid-select-methods >> >> value: (...) >> >> type: (...) >>=20 >>=20 >> > that precedes the ERT error. In this case, it appears that the >> > top-level list includes an element >>=20 >> > ("nnatom" address) >>=20 >> > which doesn't match the declared type which requires that the >> > string be followed by one of {post, mail, none, post-mail}. >>=20 >>=20 >> This should be changed to `("nnatom" none address)', and the docstri= ng >> should probably be changed to clarify this too. > That's what I've changed it to, and it was still failing, that's why I > was trying to dig more information out of the failure. > HOWEVER. Moments ago I thought to look at nnatom.el itself, and this = bit > at the bottom: > (gnus-declare-backend (symbol-name nnatom-backend) 'address) > Also ends up setting gnus-valid-select-methods, and needs the equival= ent > change: > (gnus-declare-backend (symbol-name nnatom-backend) 'none 'address) >> Honestly though, I don't understand why this is a user option in the >> first place, it only seems useful if you're implementing a new backe= nd >> (in which case, you're probably using `gnus-declare-backend', which >> modifies `gnus-valid-select-methods' without checking the value anyw= ay). > And here you mention that exact fact :) > I agree it doesn't make much sense, it doesn't do anything for the us= er. > I wonder if `gnus-declare-backend' was originally just meant to be us= ed > by out-of-tree backend libraries. Maybe the Gnus manual should indicate that `gnus-valid-select-methods' should be modified directly for built-in backends (currently it only describes using `gnus-declare-backend' in Hooking New Backends Into Gnus). > Anyway, it's redundant, but no great harm done, and the tests pass. Thanks. I also realized there is an example in nnfeed.el which is wrong in the same way, I've attached a patch which fixes it. Daniel --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-lisp-gnus-nnfeed.el-Fix-example.patch Content-Description: patch >From e4e8ed37b92125a7b68d91755cdf77d00af4b14c Mon Sep 17 00:00:00 2001 From: Daniel Semyonov Date: Mon, 29 Apr 2024 23:40:50 +0300 Subject: [PATCH] ; * lisp/gnus/nnfeed.el: Fix example --- lisp/gnus/nnfeed.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/gnus/nnfeed.el b/lisp/gnus/nnfeed.el index 0bf599553e4..d6963b2e929 100644 --- a/lisp/gnus/nnfeed.el +++ b/lisp/gnus/nnfeed.el @@ -46,7 +46,7 @@ ;; (defvoo nnfoo-read-feed-function #'nnfoo--read-feed ;; nil nnfeed-read-feed-function) ;; ... -;; (gnus-declare-backend (symbol-name nnfeed-backend) 'address) +;; (gnus-declare-backend (symbol-name nnfeed-backend) 'none 'address) ;; ;; (provide 'nnfoo) ;; -- 2.44.0 --=-=-=--