On Mon, 06 Sep 2021 09:15:24 -0700 Eric Abrahamsen wrote: > Colin Baxter writes: > >> 1. Remove all ~/.gnus.el and related files from system. >> 2. emacs-28.0.50 -Q >> 3. C-h load-history >> 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 >> 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 >> 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. I can reproduce what Colin reports. When I start Emacs from master with -Q and do `C-h v gnus-extra-headers', the value includes the X-Diary-* headers. > 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. But here I do get an error by inserting `(error "nndiary loaded")' at the end of nndiary.el, and with debug-on-error enabled, I get the attached backtrace, which indicates that the file is loaded as a consequence of `describe-variable' invoking completion on elisp library prefixes. Steve Berman