GNU bug report logs -
#74857
30.0.92; Gnus nnatom: url protocol
Previous Next
Full log
View this message in rfc822 format
>>>>> 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
This bug report was last modified 24 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.