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: 74857 <at> debbugs.gnu.org
Subject: bug#74857: 30.0.92; Gnus nnatom: url protocol
Date: Sat, 15 Mar 2025 14:17:05 +0530

Daniel Semyonov writes:

>>>>>> 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).

I suspect that those may be when -status-message is called rather than
-status-string (through nnheader), in which case it's through nnoo.

--

Previous Next

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