Re: gnus-extra-headers

[Colin Baxter <m43cap@yandex.com>]

>>>>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:

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

Yes, all installed locally under $HOME:

1. ~/local/bin/emacs-27.1 (GTK)
2. ~/local/bin/emacs-27.2 (GTK)
3. ~/local/opt/emacs-lucid/bin/emacs-27.1 (lucid)
4. ~/local/opt/emacs-lucid/bin/emacs-27.2 (lucid)
5. ~/git/emacs/src/emacs (GTK)