Reported by: Daniel Semyonov <daniel <at> dsemy.com>
Date: Wed, 21 Jun 2023 07:12:02 UTC
Severity: wishlist
Tags: patch
Merged with 66188
Found in version 29.1
Done: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Bug is archived. No further changes may be made.
View this message in rfc822 format
From: Eric Abrahamsen <eric <at> ericabrahamsen.net> To: 64202 <at> debbugs.gnu.org Subject: bug#64202: [PATCH] Gnus: Add back end for Atom feeds (nnatom) Date: Sun, 02 Jul 2023 21:01:59 -0700
Daniel Semyonov via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> 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 <address> 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/
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.