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

Previous Next

Package: emacs;

Reported by: Christopher Howard <christopher <at> librehacker.com>

Date: Fri, 13 Dec 2024 19:14:02 UTC

Severity: minor

Found in version 30.0.92

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: daniel <at> dsemy.com
Cc: christopher <at> librehacker.com, 74857 <at> debbugs.gnu.org, jimjoe <at> gmx.net
Subject: bug#74857: 30.0.92; Gnus nnatom: url protocol
Date: Sun, 13 Apr 2025 10:18:00 +0300
Ping! Ping!  Daniel, please respond.

> Cc: christopher <at> librehacker.com, 74857 <at> debbugs.gnu.org
> Date: Sat, 29 Mar 2025 14:11:58 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> Ping!  Daniel, any comments?  Should we install this?
> 
> > From: James Thomas <jimjoe <at> gmx.net>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>,  Christopher Howard
> >  <christopher <at> librehacker.com>,  74857 <at> debbugs.gnu.org
> > 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)
> > 
> > --
> > 
> 
> 
> 
> 




This bug report was last modified 23 days ago.

Previous Next


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