Re: gnus-extra-headers

[Eric Abrahamsen <eric@ericabrahamsen.net>]

On 09/06/21 19:16 PM, Stephen Berman wrote:
> On Mon, 06 Sep 2021 09:15:24 -0700 Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
>
>> 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.
>
> 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
>
> Debugger entered--Lisp error: (error "nndiary loaded")
>   signal(error ("nndiary loaded"))
>   error("nndiary loaded")
>   eval-buffer(#<buffer  *load*-113627> nil "/home/steve/src/emacs/emacs-master/lisp/gnus/nndia..." nil t)  ; Reading at buffer position 55496
>   load-with-code-conversion("/home/steve/src/emacs/emacs-master/lisp/gnus/nndia..." "/home/steve/src/emacs/emacs-master/lisp/gnus/nndia..." nil t)
>   require(nndiary)
>   eval-buffer(#<buffer  *load*> nil "/home/steve/src/emacs/emacs-master/lisp/gnus/gnus-..." nil t)  ; Reading at buffer position 1207
>   load-with-code-conversion("/home/steve/src/emacs/emacs-master/lisp/gnus/gnus-..." "/home/steve/src/emacs/emacs-master/lisp/gnus/gnus-..." t t)
>   load("gnus-diary" noerror nomessage)
>   help--load-prefixes((("gnus-" "nnselect" "nnheader" "gnus-win" "gnus-vm" "gnus-uu" "gnus-util" "gnus-undo" "gnus-topic" "gnus-sum" "gnus-start" "gnus-srvr" "gnus-spec" "gnus-score" "gnus-salt" "gnus-registry" "gnus-range" "gnus-msg" "gnus-mh" "gnus-logic" "gnus-kill" "gnus-int" "gnus-html" "gnus-group" "gnus-fun" "gnus-dup" "gnus-draft" "gnus-diary" "gnus-demon" "gnus-cus" "gnus-cite" "gnus-cache" "gnus-async" "gnus-art" "gnus-agent" "gnus" "deuglify")))
>   help--symbol-completion-table("gnus-extra-" #f(compiled-function (vv) #<bytecode 0x5932c117145b3a>) metadata)
>   completion-metadata("gnus-extra-" help--symbol-completion-table #f(compiled-function (vv) #<bytecode 0x5932c117145b3a>))
>   completion--field-metadata(20)
>   completion--do-completion(20 31)
>   completion--in-region-1(20 31)
>   #f(compiled-function (start end collection predicate) #<bytecode 0x8376d053da1c3d0>)(20 31 help--symbol-completion-table #f(compiled-function (vv) #<bytecode 0x5932c117145b3a>))
>   apply(#f(compiled-function (start end collection predicate) #<bytecode 0x8376d053da1c3d0>) (20 31 help--symbol-completion-table #f(compiled-function (vv) #<bytecode 0x5932c117145b3a>)))
>   #f(compiled-function (funs global args) #<bytecode -0x731a92f7266cda2>)(nil nil (20 31 help--symbol-completion-table #f(compiled-function (vv) #<bytecode 0x5932c117145b3a>)))
>   completion--in-region(20 31 help--symbol-completion-table #f(compiled-function (vv) #<bytecode 0x5932c117145b3a>))
>   completion-in-region(20 31 help--symbol-completion-table #f(compiled-function (vv) #<bytecode 0x5932c117145b3a>))
>   minibuffer-complete()

Awesome, this was the information we needed, thanks. I did forget that
`debug-on-error' was necessary to get the backtrace, sorry.

So I wasn't seeing the behavior because I hadn't use completion in "C-h
v". Simply completing on a gnus-prefixed symbol definitely shouldn't end
up changing the value of a variable, so I'll push something to fix this
in a bit.

Sorry this took so long to figure out!

Eric