Re: gnus-extra-headers

[Colin Baxter <m43cap@yandex.com>]

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

    > 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

I should be the one apologising for being so dim in not following simple
instructions correctly.

Best wishes,

Colin.