Subject: bug#74857: 30.0.92; Gnus nnatom: url protocol

From: Daniel Semyonov <[email-masked]>
Date: Wed, 12 Mar 2025 23:14:16 +0200

>>>>> Bug reports for GNU Emacs, the Swiss army knife of text editors writes:

    > Daniel Semyonov writes:
    >>>>>>> Eli Zaretskii writes:
    >> 
    >> >> From: Christopher Howard
    >> >> Date: Fri, 13 Dec 2024 10:13:02 -0900
    >> >> 
    >> >> 
    >> >> 
    >> >> Hi. When setting up a new feed group with nnatom in Gnus, there is a
    >> >> little oddity: If I pass in the URL to the feed without the protocol
    >> >> specifier, i.e., without the "https://" it works fine. But if I try
    >> >> to include the protocol specifier, then I get a message: "Couldn’t
    >> >> request list: nil", and the group is not added. It doesn't trigger
    >> >> the debugger, even though "debug-on-error" is set t.
    >> >> 
    >> >> So, I frequently have to delete the "https://" part when I am
    >> >> copying and pasting from some link for an atom feed. This is a
    >> >> bother.
    >> >> 
    >> >> I don't know if this can be reproduced without Gnus already
    >> >> being setup, but an example process is:
    >> >> 
    >> >> (1) bring up Gnus group buffer
    >> >> (2) run gnus-group-browse-foreign-server (B)
    >> >> (3) nnatom
    >> >> (4) https://sachachua.com/blog/category/emacs/feed/atom/
    >> 
    >> > Daniel, any comments or suggestions?
    >> 
    >> This is a known issue (also noted in the manual), though the message
    >> returned should be more descriptive.
    >> 
    >> The returned message is emitted by Gnus when it fails to get info for
    >> the server from the backend, and should use the value of
    >> 'backend-status-string' ('nnatom-status-string' in this case); this
    >> works on a normal session on my end (returning a message set in
    >> 'nnatom--read-feed'), but fails with emacs -Q, also returning "Couldn't
    >> request list: nil".
    >> I half suspect this is a bug with Gnus trying to read the status string
    >> of the wrong server (and not a bug in nnatom), but I'll look into it.

    > This seems to fix it (but maybe there's a better way):

    > diff --git a/lisp/gnus/nnatom.el b/lisp/gnus/nnatom.el
    > index 7375312b099..fe1f1272f1f 100644
    > --- a/lisp/gnus/nnatom.el
    > +++ b/lisp/gnus/nnatom.el
    > @@ -47,15 +47,14 @@ nnatom
    >  (defun nnatom--read-feed (feed _)
    >    "Return a list structure representing FEED, or nil."
    >    (if (string-match-p "\\`https?://" feed)
    > -      (nnheader-report
    > -       nnatom-backend
    > +      (nnfeed-report
    >         "Address shouldn't start with \"http://\" or \"https://\"")
    >      (with-temp-buffer
    >        (condition-case e
    >            (if (file-name-absolute-p feed)
    >                (insert-file-contents feed)
    >              (mm-url-insert-file-contents (concat "https://" feed)))
    > -        (file-error (nnheader-report nnatom-backend (cdr e)))
    > +        (file-error (nnfeed-report (cdr e)))
    >          (:success (when-let ((data (if (libxml-available-p)
    >                                         (libxml-parse-xml-region
    >                                          (point-min) (point-max))
    > diff --git a/lisp/gnus/nnfeed.el b/lisp/gnus/nnfeed.el
    > index ffea063038e..e0489044929 100644
    > --- a/lisp/gnus/nnfeed.el
    > +++ b/lisp/gnus/nnfeed.el
    > @@ -687,6 +687,9 @@ nnfeed-request-rename-group
    >           (setq nnfeed-group new-name))
    >      t))
 
    > +(deffoo nnfeed-report (&rest args)
    > +  (apply #'nnheader-report 'nnfeed args))
    > +
    >  (provide 'nnfeed)
 
    >  ;;; nnfeed.el ends here

    > For those who're wondering what's going on, (info "(gnus) Writing New
    > Back Ends") says:

    >   This means that ‘nnml-current-directory’ will be set to
    >   ‘nndir-directory’ when an ‘nnml’ function is called on behalf of
    >   ‘nndir’.  (The same with ‘nnmh’.)

    > (FTR, I hate OOP)

Thank you very much for looking into this, I'm assuming this means that
Gnus tries to use the value of 'nnfeed-status-string', instead of the
nnatom equivalent, right? (I honestly also hate OOP, and I find the
flavor implemented in Gnus especially confusing).
If so, this seems like a good solution, though I wonder why it works
without this fix sometimes (and if it'll still work in those cases with
this applied).

Thanks again for looking into this,
Daniel