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: Daniel Semyonov <daniel <at> dsemy.com>
To: Eli Zaretskii <eliz <at> gnu.org>
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 16:48:46 +0300
[Message part 1 (text/plain, inline)]
>>>>> Eli Zaretskii writes:

    > Ping! Ping!  Daniel, please respond.

Sorry, I wanted to have a better understanding of the issue first, but
James' patch seems to work well AFAICT from testing; I've attached a
simpler patch which basically achieves the same result, which I think
should be applied.

>>>>> James Thomas writes:

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

AFAICT the issue occurs when -status-message is called, actually,
through 'gnus-status-message', see 'gnus-browse-foreign-server':

(defun gnus-browse-foreign-server (server &optional return-buffer)
  "Browse the server SERVER."
  ...
    (cond
     ((not (gnus-check-server method))
      (gnus-message
       1 "Unable to contact server %s: %s" (nth 1 method)
       (gnus-status-message method))
      nil)
     ((not
       (prog2
	   (gnus-message 6 "Reading active file...")
	   (gnus-request-list method)
	 (gnus-message 6 "Reading active file...done")))
      (gnus-message
       1 "Couldn't request list: %s" (gnus-status-message method))
      nil)
  ...

Stepping through with Edebug, it seems the actual function called is
'nnatom-status-message' as expected, only that it returns nil; with the
patch (yours or mine) applied, it returns the expected string.
'nnatom-status-message' is defined through
'nnfeed-define-basic-backend-interface', and its definition should be:

(deffoo nnatom-status-message (&optional server)
  (nnoo-status-message 'nnatom server)))

'nnoo-status-message' uses nnheader to get the status string for the
correct backend, but it returns nil; my patch uses the same method to
get the same string, and set it for the parent backend (nnfeed) as well,
when failing to request a list, which somehow causes
'nnatom-status-message' to return the correct string (even though the
value it should read is not modified by my patch or yours).

In any case, I would appreciate any more insight into this.

Daniel

[0001-nnfeed-Pass-through-list-request-failure-reports.patch (text/x-patch, attachment)]

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.