GNU bug report logs - #74857
30.0.92; Gnus nnatom: url protocol

Previous Next

Full log

View this message in rfc822 format

From: James Thomas <jimjoe <at> gmx.net>
To: Daniel Semyonov <daniel <at> dsemy.com>
Cc: Christopher Howard <christopher <at> librehacker.com>, Eli Zaretskii <eliz <at> gnu.org>, 74857 <at> debbugs.gnu.org
Subject: bug#74857: 30.0.92; Gnus nnatom: url protocol
Date: Tue, 11 Mar 2025 17:38:13 +0530

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)

--

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.