bug#54423: 29.0.50; gnus-fetch-original-field returns nil in digest

bug#54423: 29.0.50; gnus-fetch-original-field returns nil in digest

[Sam Steingold]

In the group gmane.comp.security.risks on server nntp:news.gmane.io open
an article and type C-d (gnus-summary-enter-digest-group).
Then enter a message from the summary buffer (e.g., SPC)
and now (gnus-fetch-original-field "Newsgroups") returns nil instead of
"gmane.comp.security.risks" as it should.
The variable gnus-original-article-buffer evaluates to
" *Original Article gmane.comp.security.risks*"
and that buffer starts like this:

--8<---------------cut here---------------start------------->8---
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: RISKS List Owner <risko@csl.sri.com>
Newsgroups: gmane.comp.security.risks
Subject: Risks Digest 33.09
Date: Tue, 15 Mar 2022 16:23:26 PDT
Approved: news@gmane.org
Message-ID: <CMM.0.90.4.1647386606.risko@chiron.csl.sri.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214";
	logging-data="10317"; mail-complaints-to="usenet@ciao.gmane.io"
To: risks-resend@csl.sri.com
...
--8<---------------cut here---------------end--------------->8---



In GNU Emacs 29.0.50 (build 4, x86_64-apple-darwin21.3.0, NS appkit-2113.30 Version 12.2.1 (Build 21D62))
 of 2022-03-14 built on 3c22fb11fdab.ant.amazon.com
Repository revision: 1c4421183ed93fb033e17934205934ca3c423908
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2113
System Description:  macOS 12.2.1

Configured using:
 'configure --with-imagemagick --with-mailutils --with-ns
 PKG_CONFIG_PATH='

Configured features:
ACL GIF GMP GNUTLS IMAGEMAGICK JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY
KQUEUE NS PDUMPER PNG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP ZLIB

Important settings:
  value of $LANG: C
  locale-coding-system: utf-8-unix

Major mode: Group

Minor modes in effect:
  shell-dirtrack-mode: t
  gnus-undo-mode: t
  global-edit-server-edit-mode: t
  winner-mode: t
  which-function-mode: t
  url-handler-mode: t
  desktop-save-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t

Load-path shadows:
None found.

Features:
(shadow emacsbug bbdb-message mailalias sendmail cookie1 debug pulse
color xref project grep edebug backtrace shortdoc nndoc sort smiley
gnus-cite textsec uni-scripts idna-mapping uni-confusable textsec-check
gnus-async gnus-bcklg gnus-dup mail-extr gnus-ml hl-line disp-table spam
spam-stat gnus-uu yenc nndraft nnmh gnus-agent gnus-srvr gnus-score
score-mode nnvirtual gnus-msg utf-7 gnus-cache bbdb-gnus gnutls
network-stream nsm nntp cal-move dabbrev log-view vc-annotate misearch
multi-isearch cl-print help-fns radix-tree skeleton log-edit pcvs-util
smerge-mode diff vc-mtn vc-src vc-sccs vc-svn vc-cvs vc-rcs pcase
package compile add-log vc-hg vc-bzr tramp-cache tramp-sh tramp
tramp-loaddefs trampver tramp-integration cus-edit pp cus-start files-x
tramp-compat shell ls-lisp remember flyspell ispell org-element avl-tree
generator cl-extra help-mode ol-eww eww xdg url-queue thingatpt mm-url
ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect gnus-art mm-uu mml2015
mm-view mml-smime smime dig gnus-sum shr pixel-fill kinsoku url-file
url-dired svg dom browse-url url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util gnus-group
gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail
mail-source utf7 netrc nnoo parse-time gnus-spec gnus-int gnus-range
message mailcap yank-media rmc puny rfc822 mml mml-sec epa derived epg
rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231
rfc2047 rfc2045 ietf-drums gmm-utils mailheader gnus-win ol-docview
doc-view jka-compr image-mode exif dired dired-loaddefs ol-bibtex
ol-bbdb ol-w3m ol-doi org-link-doi org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro org-footnote org-src ob-comint org-pcomplete
pcomplete comint ansi-color org-list org-faces org-entities noutline
outline org-version ob-emacs-lisp ob-core ob-eval org-table oc-basic
bibtex iso8601 ol rx org-keys oc org-compat org-macs org-loaddefs
format-spec find-func cal-x view cal-china cal-bahai cal-islam holidays
hol-loaddefs bbdb-anniv cal-iso cal-hebrew lunar cal-julian solar
cal-dst appt diary-lib diary-loaddefs cal-menu calendar cal-loaddefs
vc-dir ewoc vc bug-reference vc-git diff-mode easy-mmode vc-dispatcher
midnight warnings gnus nnheader gnus-util text-property-search time-date
mail-utils range mm-util mail-prsvr wid-edit bbdb-mua bbdb-com crm
mailabbrev bbdb bbdb-site timezone edit-server advice server winner ring
which-func imenu url-handlers url-parse auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json map seq gv subr-x
byte-opt bytecomp byte-compile cconv url-vars help-at-pt desktop
frameset cl-loaddefs cl-lib cus-load info iso-transl tooltip eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/ns-win ns-win ucs-normalize mule-util term/common-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget keymap hashtable-print-readable backquote threads
kqueue cocoa ns lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 725528 101544)
 (symbols 48 30868 14)
 (strings 32 241311 4085)
 (string-bytes 1 6143183)
 (vectors 16 88608)
 (vector-slots 8 1265635 76111)
 (floats 8 1234 740)
 (intervals 56 17524 3282)
 (buffers 992 81))

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.2113
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
https://www.dhimmitude.org https://thereligionofpeace.com
Parachute for sale, used once, never opened, small stain.

bug#54423: 29.0.50; gnus-fetch-original-field returns nil in digest

[Lars Ingebrigtsen]

Sam Steingold <sds@gnu.org> writes:

> In the group gmane.comp.security.risks on server nntp:news.gmane.io open
> an article and type C-d (gnus-summary-enter-digest-group).
> Then enter a message from the summary buffer (e.g., SPC)
> and now (gnus-fetch-original-field "Newsgroups") returns nil instead of
> "gmane.comp.security.risks" as it should.
> The variable gnus-original-article-buffer evaluates to
> " *Original Article gmane.comp.security.risks*"
> and that buffer starts like this:

I think there's a misunderstanding here -- the "original" that the
function is fetching is the unformatted "original" version of the thing
that's displayed in the *Article* buffer.  It has nothing to do with how
the article was sourced (which was via a digest in this case).

So this is working as designed.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#54423: 29.0.50; gnus-fetch-original-field returns nil in digest

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So this is working as designed.

If you want to get at the newsgroup name of the parent group, that's
stashed in the info params, so you should be able to get at that data
via something like:

(gnus-info-params (gnus-get-info gnus-newsgroup-name))

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#54423: 29.0.50; gnus-fetch-original-field returns nil in digest

[Sam Steingold]

> * Lars Ingebrigtsen <ynefv@tahf.bet> [2022-03-17 13:06:08 +0100]:
>
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> So this is working as designed.
>
> If you want to get at the newsgroup name of the parent group, that's
> stashed in the info params, so you should be able to get at that data
> via something like:
>
> (gnus-info-params (gnus-get-info gnus-newsgroup-name))

for gnus-newsgroup-name = "gmane.comp.security.risks", the above returns

--8<---------------cut here---------------start------------->8---
((timestamp . 1647530087))
--8<---------------cut here---------------end--------------->8---

How do I get the headers like "Newsgroups" or "Content-Type"?

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.2113
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
https://honestreporting.com https://jij.org https://ffii.org
Who is General Failure and why is he reading my hard disk?

bug#54423: 29.0.50; gnus-fetch-original-field returns nil in digest

[Sam Steingold]

I added bbdb-user to CC.

For context (see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54423 for
full details), the problem is that `bbdb-message-header' calls
`gnus-fetch-original-field' which, for a digest group, returns nil.
This prevents `bbdb-accept-message-alist' from working for, e.g.,

--8<---------------cut here---------------start------------->8---
(("Newsgroups" . "\\(gmane\\.emacs\\|gmane\\.comp\\.security\\.risks\\)"))
--8<---------------cut here---------------end--------------->8---

because every message in gmane.comp.security.risks is a digest.

> * Lars Ingebrigtsen <ynefv@tahf.bet> [2022-03-17 11:59:43 +0100]:
>
> Sam Steingold <sds@gnu.org> writes:
>
>> In the group gmane.comp.security.risks on server nntp:news.gmane.io open
>> an article and type C-d (gnus-summary-enter-digest-group).
>> Then enter a message from the summary buffer (e.g., SPC)
>> and now (gnus-fetch-original-field "Newsgroups") returns nil instead of
>> "gmane.comp.security.risks" as it should.
>> The variable gnus-original-article-buffer evaluates to
>> " *Original Article gmane.comp.security.risks*"
>> and that buffer starts like this:
>
> I think there's a misunderstanding here -- the "original" that the
> function is fetching is the unformatted "original" version of the thing
> that's displayed in the *Article* buffer.  It has nothing to do with how
> the article was sourced (which was via a digest in this case).
>
> So this is working as designed.

Okay, so how do I extract "Newsgroups" or "Content-Type" for a message
in a digest?

Thank you Lars.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.2113
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
https://mideasttruth.com https://jij.org https://honestreporting.com
I may be getting older, but I refuse to grow up!

bug#54423: 29.0.50; gnus-fetch-original-field returns nil in digest

[Lars Ingebrigtsen]

Sam Steingold <sds@gnu.org> writes:

>> (gnus-info-params (gnus-get-info gnus-newsgroup-name))
>
> for gnus-newsgroup-name = "gmane.comp.security.risks", the above returns
>
> ((timestamp . 1647530087))

You have to call that in the nndoc group.

> How do I get the headers like "Newsgroups" or "Content-Type"?

I don't think the latter is stored anywhere.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#54423: 29.0.50; gnus-fetch-original-field returns nil in digest

[Roland Winkler]

On Thu, Mar 17 2022, Sam Steingold wrote:
> the problem is that `bbdb-message-header' calls
> `gnus-fetch-original-field' which, for a digest group, returns nil.
> This prevents `bbdb-accept-message-alist' from working for, e.g.,
>
> (("Newsgroups" . "\\(gmane\\.emacs\\|gmane\\.comp\\.security\\.risks\\)"))
>
> because every message in gmane.comp.security.risks is a digest.

While I included the call of `gnus-fetch-original-field' in
`bbdb-message-header', I need to admit that the above issue goes much
beyond my knowledge of Gnus internals.  If there are better ways for
`bbdb-message-header' to achieve what it needs to achieve (which is
grabbing the content of (what appear to be) headers of a message),
then I certainly appreciate any patches for BBDB.

Roland

bug#54423: 29.0.50; gnus-fetch-original-field returns nil in digest

[Lars Ingebrigtsen]

Roland Winkler <winkler@gnu.org> writes:

> While I included the call of `gnus-fetch-original-field' in
> `bbdb-message-header', I need to admit that the above issue goes much
> beyond my knowledge of Gnus internals.  If there are better ways for
> `bbdb-message-header' to achieve what it needs to achieve (which is
> grabbing the content of (what appear to be) headers of a message),
> then I certainly appreciate any patches for BBDB.

If the intention is to collect data from the parent group (which is a
thing mostly just for nndoc groups), you first have to determine what
the parent group is, and then you can select the data from the buffer
that's named something like " *Original Article group.name*".

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#54423: 29.0.50; gnus-fetch-original-field returns nil in digest

[Roland Winkler]

On Thu, Mar 17 2022, Lars Ingebrigtsen wrote:
> If the intention is to collect data from the parent group (which is a
> thing mostly just for nndoc groups), you first have to determine what
> the parent group is, and then you can select the data from the buffer
> that's named something like " *Original Article group.name*".

Thanks for the clarification! - This brings me back to what I said: if
someone more knowledgable of Gnus internals can translate the above into
code for `bbdb-message-header', I'll appreciate that.  I can also try do
that myself.  But then I cannot promise anything.

bug#54423: 29.0.50; gnus-fetch-original-field returns nil in digest

[Sam Steingold]

> * Lars Ingebrigtsen <ynefv@tahf.bet> [2022-03-17 20:43:26 +0100]:
>
> Roland Winkler <winkler@gnu.org> writes:
>
>> While I included the call of `gnus-fetch-original-field' in
>> `bbdb-message-header', I need to admit that the above issue goes much
>> beyond my knowledge of Gnus internals.  If there are better ways for
>> `bbdb-message-header' to achieve what it needs to achieve (which is
>> grabbing the content of (what appear to be) headers of a message),
>> then I certainly appreciate any patches for BBDB.
>
> If the intention is to collect data from the parent group (which is a
> thing mostly just for nndoc groups), you first have to determine what
> the parent group is, and then you can select the data from the buffer
> that's named something like " *Original Article group.name*".

...which brings us back to my original message ;-)

Specifically, `bbdb-message-header' calls

--8<---------------cut here---------------start------------->8---
(defun gnus-fetch-original-field (field)
  "Fetch FIELD from the original version of the current article."
  (with-current-buffer gnus-original-article-buffer
    (gnus-fetch-field field)))
--8<---------------cut here---------------end--------------->8---

The variable gnus-original-article-buffer evaluates to
" *Original Article gmane.comp.security.risks*"
and that buffer starts like this:

--8<---------------cut here---------------start------------->8---
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: RISKS List Owner <risko@csl.sri.com>
Newsgroups: gmane.comp.security.risks
Subject: Risks Digest 33.09
Date: Tue, 15 Mar 2022 16:23:26 PDT
Approved: news@gmane.org
Message-ID: <CMM.0.90.4.1647386606.risko@chiron.csl.sri.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214";
	logging-data="10317"; mail-complaints-to="usenet@ciao.gmane.io"
To: risks-resend@csl.sri.com
...
--8<---------------cut here---------------end--------------->8---

and (gnus-fetch-original-field "Newsgroups") returns nil even though the
original article buffer contains the appropriate header...

Thank you for your kind attention.


-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.2113
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
http://think-israel.org https://jihadwatch.org https://iris.org.il
Those who can laugh at themselves will never cease to be amused.

bug#54423: 29.0.50; gnus-fetch-original-field returns nil in digest

[Lars Ingebrigtsen]

Sam Steingold <sds@gnu.org> writes:

> The variable gnus-original-article-buffer evaluates to
> " *Original Article gmane.comp.security.risks*"

Evaluates to that where?  It's usually a buffer-local variable.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#54423: 29.0.50; gnus-fetch-original-field returns nil in digest

[Sam Steingold]

> * Lars Ingebrigtsen <ynefv@tahf.bet> [2022-03-17 11:59:43 +0100]:
>
> Sam Steingold <sds@gnu.org> writes:
>
>> In the group gmane.comp.security.risks on server nntp:news.gmane.io open
>> an article and type C-d (gnus-summary-enter-digest-group).
>> Then enter a message from the summary buffer (e.g., SPC)
>> and now (gnus-fetch-original-field "Newsgroups") returns nil instead of
>> "gmane.comp.security.risks" as it should.
>> The variable gnus-original-article-buffer evaluates to
>> " *Original Article gmane.comp.security.risks*"
>> and that buffer starts like this:
>
> I think there's a misunderstanding here -- the "original" that the
> function is fetching is the unformatted "original" version of the thing
> that's displayed in the *Article* buffer.  It has nothing to do with how
> the article was sourced (which was via a digest in this case).

Nevertheless, the '''unformatted "original" version of the thing
that's displayed in the *Article* buffer''' is the
`gnus-original-article-buffer' which points to buffer
" *Original Article gmane.comp.security.risks*"
which _does_ contain all the needed goodies,
_BUT_ `gnus-fetch-original-field' does _NOT_ return them.

IOW, `mail-fetch-field',
called by `message-fetch-field',
called by `gnus-fetch-field',
called by `gnus-fetch-original-field',
returns nil.

`gnus-fetch-original-field' calls `gnus-fetch-field'
inside `with-current-buffer gnus-original-article-buffer`
and the buffer referenced by `gnus-original-article-buffer'
_does_ contain the fields in the header.

> So this is working as designed.

Then how should bbdb extract the "Newsgroups" et al?

Thank you!

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.2113
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
https://iris.org.il https://memri.org https://mideasttruth.com
Man has 2 states: hungry/angry and sate/sleepy.  Catch him in transition.

bug#54423: 29.0.50; gnus-fetch-original-field returns nil in digest

[Sam Steingold]

Context (see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54423):
`bbdb-message-header' calls `gnus-fetch-original-field' which,
for a digest ("nndoc") group, returns nil for every header.

The root of the problem is that `gnus-fetch-original-field' relies on
`gnus-original-article-buffer' which is buffer-local:

--8<---------------cut here---------------start------------->8---
gnus-original-article-buffer is a variable defined in ‘gnus.el’.

Its value is
" *Original Article nndoc:gmane.comp.security.risks-1023*"
Local in buffer *Summary nndoc:gmane.comp.security.risks-1023*; global value is the same.
--8<---------------cut here---------------end--------------->8---

(buffer " *Original Article nndoc:gmane.comp.security.risks-1023*" is _empty_!)
and at the _same_ time (no gnus command executed, just a buffer switch):

--8<---------------cut here---------------start------------->8---
gnus-original-article-buffer is a variable defined in ‘gnus.el’.

Its value is " *Original Article gmane.comp.security.risks*"
Local in buffer *Summary gmane.comp.security.risks*; global value is the same.
--8<---------------cut here---------------end--------------->8---

Lars suggested that I use this:

--8<---------------cut here---------------start------------->8---
(gnus-info-params (gnus-get-info gnus-newsgroup-name))
--8<---------------cut here---------------end--------------->8---

and it appears that the following works:

--8<---------------cut here---------------start------------->8---
diff --git a/lisp/bbdb-mua.el b/lisp/bbdb-mua.el
index f9d141d..ab3863c 100644
--- a/lisp/bbdb-mua.el
+++ b/lisp/bbdb-mua.el
@@ -111,7 +111,17 @@ MIME encoded headers are decoded.  Return nil if HEADER does not exist."
                      ;; `bbdb-select-message' does not get fooled by an apparent
                      ;; absence of some headers.
                      ;; See http://permalink.gmane.org/gmane.emacs.gnus.general/78741
-                     (eq mua 'gnus) (gnus-fetch-original-field header))
+                     (eq mua 'gnus)
+                     (or (gnus-fetch-original-field header)
+                         ;; See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54423
+                         ;; 'gnus-fetch-original-field' returns nil in nndoc groups
+                         ;; (digests) because the 'qgnus-original-article-buffer' is
+                         ;; empty for the nndoc summary but not for the parent summary.
+                         (and-let* ((i (gnus-get-info gnus-newsgroup-name))
+                                    (p (gnus-info-params i))
+                                    (parent-summary-buffer (cadr (assq 'quit-config p))))
+                           (with-current-buffer parent-summary-buffer
+                             (gnus-fetch-original-field header)))))
                     ((eq mua 'vm) (bbdb/vm-header header))
                     ((eq mua 'rmail)
                      (with-current-buffer rmail-buffer
--8<---------------cut here---------------end--------------->8---

`quit-config' contains the parent summary buffer object.
I would rather use that directly that construct the string
" *Original Article gmane.comp.security.risks*"
(especially since the relevant logic in `gnus-article-setup-buffer' is
moderately convoluted).

The question is whether this is TRT or there is a better way.

Thanks to Lars for his patience, and to everyone else for possible
suggestion.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.2113
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
https://honestreporting.com https://camera.org http://think-israel.org
Money does not bother me at all.  In fact, it calms me down.

bug#54423: 29.0.50; gnus-fetch-original-field returns nil in digest

[Roland Winkler]

On Mon, Mar 21 2022, Sam Steingold wrote:
> Lars suggested that I use this:
>
> (gnus-info-params (gnus-get-info gnus-newsgroup-name))
>
> and it appears that the following works:
>
[snip]
> +          (and-let* ((i (gnus-get-info gnus-newsgroup-name))
> +                     (p (gnus-info-params i))
> +                     (parent-summary-buffer (cadr (assq 'quit-config p))))
> +            (with-current-buffer parent-summary-buffer
> +              (gnus-fetch-original-field header)))))

...Is the (and-let*... needed?  Of course, one could wrap all code that
way.  But and-let* is not even part of Emacs 25 that current BBDB is
supposed to support.  Also, if the above code should fail in certain
cases, it might be an indication that the above code is not yet exactly
what is needed so that this should not be swept under the carpet.  So I
feel that
 
  (with-current-buffer (cadr (assq 'quit-config
                                   (gnus-info-params
                                    (gnus-get-info gnus-newsgroup-name))))

is the better way to go.  Am I missing something?

Or: If the corner cases when the code can still fail are known and the
failure is in that sense intentional, this should be made more explicit
in the code.