bug#64202: [PATCH] Gnus: Add back end for Atom feeds (nnatom)

[Eric Abrahamsen]

Daniel Semyonov via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@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/