Re: gnus-extra-headers

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Colin Baxter <m43cap@yandex.com> writes:

> 1.  Remove all ~/.gnus.el and related files from system.
> 2.  emacs-28.0.50 -Q <RET>
> 3.  C-h load-history <RET>
> 4.  Search for loaded gnus libraries.
> 5.  2 matches for "gnus" in buffer: *Help*
>     3994:  (defun . gnus-batch-kill)
>     3995:  (defun . gnus-set-sorted-intersection)
>     No nndiary loaded.
> 6.  C-h gnus-extra-headers <RET>
> 7.  (X-Diary-Time-Zone X-Diary-Dow X-Diary-Year X-Diary-Month X-Diary-Dom
>     X-Diary-Hour X-Diary-Minute To Cc Keywords Gcc Newsgroups X-GM-LABELS) 
>     Original value was 
>     (To Cc Keywords Gcc Newsgroups X-GM-LABELS)
> 8.  C-h load-history <RET>
> 9.  Search for loaded gnus libraries.
> 10. 4874 matches in 3654 lines for "gnus" in buffer: *Help*
>     94 matches in 65 lines for "nndiary" in buffer: *Help*
>
>
> It appears that finding the value of gnus-extra-headers by means of C-h
> loads various gnus and nndiary libraries. We cannot find the "original
> value" of gnus-extra-headers because we cannot avoid loading nndiary
> libraries.
>
> Is this expected?

No, none of that is expected, and it's not what I see here. Doing C-h v
gnus-extra-headers does load a bunch of Gnus files, but not nndiary, and
the value of the option doesn't change.

And the fact that putting a call to (error) (actually, it should have
been called with a string argument, but the effect is the same) in
nndiary.el doesn't actually raise an error and give you a traceback
means that you're not loading that file at all. Are there are multiple
Emacs installations on your machine?