From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.bugs Subject: bug#64202: [PATCH] Gnus: Add back end for Atom feeds (nnatom) Date: Sun, 02 Jul 2023 21:01:59 -0700 Message-ID: <87a5wdskw8.fsf@ericabrahamsen.net> References: <87v8fhmgvw.fsf@dsemy.com> <87y1k76eip.fsf@dsemy.com> <87fs6epd6d.fsf@dsemy.com> <87bkh2p96o.fsf@dsemy.com> <83ilb4qb44.fsf@gnu.org> <87r0prkgsz.fsf@dsemy.com> <873525udhn.fsf@ericabrahamsen.net> <87pm59984x.fsf@dsemy.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18417"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: 64202@debbugs.gnu.org Cancel-Lock: sha1:3pOGjItEhKFneVT0y2vK/qx/kXg= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 03 06:03:41 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1qGAmq-0004ZM-RV for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 03 Jul 2023 06:03:40 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qGAmM-0002T0-F8; Mon, 03 Jul 2023 00:03:10 -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 1qGAmF-0002Sm-DC for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 00:03:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qGAmE-00025O-Ga for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 00:03:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qGAmE-0003rV-8t for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 00:03:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <87v8fhmgvw.fsf@dsemy.com> Resent-From: Eric Abrahamsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 03 Jul 2023 04:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64202 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.168835694814799 (code B ref -1); Mon, 03 Jul 2023 04:03:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 3 Jul 2023 04:02:28 +0000 Original-Received: from localhost ([127.0.0.1]:33000 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGAlg-0003qc-1n for submit@debbugs.gnu.org; Mon, 03 Jul 2023 00:02:28 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:54454) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGAlb-0003qR-8t for submit@debbugs.gnu.org; Mon, 03 Jul 2023 00:02:26 -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 1qGAla-0002Pk-8N for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 00:02:22 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGAlY-0001y5-1d for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 00:02:21 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qGAlT-0002dE-SK for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 06:02:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geb-bug-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:264507 Archived-At: Daniel Semyonov via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: >>>>>> Eric Abrahamsen writes: > > > Thanks again for working on this -- I'm getting around to trying > > it out. I have a dumb first question: how do I create a Atom > > group? I wanted to try it out with the US weather.gov feed for my > > state: https://alerts.weather.gov/cap/wa.php?x=0 > > > I tried with "a" in the *Server* buffer, "G m" in the *Group* > > buffer, but I guess neither allow for prompting the user for a > > URL. > > You can use "B nnatom RET
RET" in the group buffer for this > purpose. Huh! In all my years of using and working on Gnus I've never used a "foreign" server, nor have I really understood what it means. At some point it would be good to make sure this works via other entrypoints as well, but so far so good. > > I also added > > > (nnatom "alerts.weather.gov/cap/wa.php?x=0) > > > to my `gnus-secondary-select-methods' variable, but it said > > "Server file alerts.weather.gov/cap/wa.php?x=0 not readable or > > writable" when I restarted Gnus. I guess because we're going > > straight to `nnatom-open-server', which reads a local file, > > without ever fetching the file. We'd have to hit > > `nnatom--parse-feed' to do that, but I don't see how we arrive > > there without already having the server created. > > The server should be allowed to open without an existing local file, as > long as that local file is writable, however... > > > What am I missing? > > You're not missing anything, you actually just reminded me of a bug I > forgot to fix - the directory holding the local feed data isn't > automatically created if it's missing, which causes 'file-writable-p' to > return nil, preventing the server from opening. As a workaround, > manually create an "atom" subdir under 'gnus-directory'. I'll fix this > in the next version. Yup, that did the trick. > However, this particular feed still doesn't work since the comment at > the start of the feed changes the structure of the parsed representation > of the feed when libxml is supported (this also made me realize I > accidentally broke parsing without libxml in the last version, oops). > This is very useful info, as this is the first feed I encountered like > this, and I will fix both those issues too in the next version. > > As a quick fix, redefine 'nnatom--read-feed' as: > > (defun nnatom--read-feed (feed _) > "Return a list structure representing FEED, or nil." > (if (string-match-p "^https?://" feed) > (nnheader-report > nnatom-backend > "Address shouldn't start with \"http://\" or \"https://\"") > (with-temp-buffer > (condition-case e > (if (file-readable-p feed) > (insert-file-contents feed) > (mm-url-insert-file-contents (concat "https://" feed))) > (file-error (nnheader-report nnatom-backend (cdr e))) > (:success (when-let ((data (if (libxml-available-p) > (libxml-parse-xml-region > (point-min) (point-max)) > (car (xml-parse-region > (point-min) (point-max))))) > (auth (list 'authors))) > (when (eq (car data) 'top) > (setq data (assq 'feed data))) > (dom-add-child-before data auth) > (catch :stop ; Collect feed authors, stop at first entry. > (dolist (child (cdddr data) data) > (let ((tag (car-safe child))) > (if (eq tag 'entry) > (throw :stop data) > (and (or (eq tag 'author) > (eq tag 'contributor)) > (dom-add-child-before auth child)))))))))))) Yes, that fixed it. I'll do some more poking around. Regarding your earlier question about having this backend handle RSS too, I'm not aware of any significant difference between the two beyond the format of the XML. Is that true? If so, it seems like it would make most sense to merge the code. Have you looked at nnrss? It would be good to know if there was anything in there worth stealing for nnatom -- if one of them has a faster parser than the other, for instance, or better logic for keeping updates efficient. I just subscribed to a feed with nnrss, and noticed that after I marked all the items in the feed as read, I couldn't re-enter the group and see the old items. It gave me "Can't select group". So that's not very encouraging. If you do want to expand this to be a general "feed" backend, we might want to do some boring things like rename it nnfeed.el, and add support for ridiculous things like JSON feed[0] (why?!?). I assume a derived backend could handle JSON feeds by setting the appropriate values for the `nnatom-read-*-function' deffoos? One of the awkward things about nnrss is that it's never really fit well into Gnus' one-server-many-groups paradigm, which you allude to in the nnatom Info section. Do you have any further ideas in that direction? Thanks, Eric [0]: https://www.jsonfeed.org/