From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13685 invoked from network); 7 Sep 2021 05:54:04 -0000 Received: from mx1.math.uh.edu (129.7.128.32) by inbox.vuxu.org with ESMTPUTF8; 7 Sep 2021 05:54:04 -0000 Received: from lists1.math.uh.edu ([129.7.128.208]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mNU3V-00GVom-7N for ml@inbox.vuxu.org; Tue, 07 Sep 2021 00:54:01 -0500 Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.94) (envelope-from ) id 1mNU3U-002Qhf-Np for ml@inbox.vuxu.org; Tue, 07 Sep 2021 00:54:00 -0500 Received: from mx2.math.uh.edu ([129.7.128.33]) by lists1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1mNU3S-002QhR-1D for ding@lists.math.uh.edu; Tue, 07 Sep 2021 00:53:58 -0500 Received: from quimby.gnus.org ([95.216.78.240]) by mx2.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1mNU3P-006tPZ-46 for ding@lists.math.uh.edu; Tue, 07 Sep 2021 00:53:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=TgnW6CgwwE29W+uE3bv5QpYkAUoYAquOFhKFyonvwaY=; b=VRldZEMFHXL2XM/7Kzrp+zqsz8 u72AtsnK6zniHCnhFOuJtRqBevkx8j5t/vkQtrsciBdfxXwp+60N5/op7BcsEdlOkZ9jKCvMtt3mb RmdSXs0yUGW0fPmM7x5pb2u2J9iRIybE+j60oeZieKwYW22t9LG7Vrp3pCG3/Quyy4OY=; Received: from forward103p.mail.yandex.net ([2a02:6b8:0:1472:2741:0:8b7:106]) by quimby.gnus.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mNU3G-0001ro-1y for ding@gnus.org; Tue, 07 Sep 2021 07:53:48 +0200 Received: from myt6-42bc0fbd6fd0.qloud-c.yandex.net (myt6-42bc0fbd6fd0.qloud-c.yandex.net [IPv6:2a02:6b8:c12:4e08:0:640:42bc:fbd]) by forward103p.mail.yandex.net (Yandex) with ESMTP id EB2015A0949; Tue, 7 Sep 2021 08:53:43 +0300 (MSK) Received: from myt6-016ca1315a73.qloud-c.yandex.net (myt6-016ca1315a73.qloud-c.yandex.net [2a02:6b8:c12:4e0e:0:640:16c:a131]) by myt6-42bc0fbd6fd0.qloud-c.yandex.net (mxback/Yandex) with ESMTP id 11JyCXcuaj-rhDuci2j; Tue, 07 Sep 2021 08:53:43 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1630994023; bh=TgnW6CgwwE29W+uE3bv5QpYkAUoYAquOFhKFyonvwaY=; h=In-Reply-To:Subject:Date:References:To:From:Message-ID:Cc:Cc; b=saaiEsghXI5EfCDumILxUoLDlED07I3sk4jJoZS9Y4vfARoWtoSlGyFBII7keVtks mgep5QzDlGT44pDWUgR3ybH05MRFGYh7I0nK4QwjmjUhg/IvdT3JUUJIY3OWJswloN CVvkiuKUnPk00d08IaZ3T/KT9WLMfAobNXAJrgJM= Authentication-Results: myt6-42bc0fbd6fd0.qloud-c.yandex.net; dkim=pass header.i=@yandex.com Received: by myt6-016ca1315a73.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id WKOXxxxvKE-rg1GifVx; Tue, 07 Sep 2021 08:53:42 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) From: Colin Baxter To: Eric Abrahamsen Cc: Stephen Berman , ding@gnus.org Cc: Subject: Re: gnus-extra-headers References: <87sfyohftb.fsf@yandex.com> <87sfymy6ck.fsf@ericabrahamsen.net> <87y28e6wr1.fsf@yandex.com> <875yvhldf3.fsf@ericabrahamsen.net> <87wnnwv1zy.fsf@yandex.com> <87wnnwid8l.fsf@ericabrahamsen.net> <87bl57to59.fsf@yandex.com> <87sfyiidmf.fsf@ericabrahamsen.net> <87lf4atbu0.fsf@yandex.com> <87h7eyt7zo.fsf@yandex.com> <87lf49istf.fsf@ericabrahamsen.net> <87zgsppquh.fsf@rub.de> <877dftim4f.fsf@ericabrahamsen.net> X-Face: BHjiJOg/Qmj'BQgsAKL@])L)e62P)C"Y=6T X-Message-My-Extra-Message: 8-) We are the only ones here =?utf-8?B?8J+YuiDwn5i6IPCfmLo=?= Date: Tue, 07 Sep 2021 06:53:40 +0100 In-Reply-To: <877dftim4f.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Mon, 06 Sep 2021 11:40:00 -0700") Message-ID: <87eea13p97.fsf@yandex.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAAEkAAAATAgMAAAChCMjeAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAACVBMVEX/zAABCWP///8I RHjYAAAAAWJLR0QCZgt8ZAAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB+UFEAk5BvqS634A AAAbSURBVBjTY2BgCA1hYA0FAxDDgQEERsXoIAYA2F9Eb3cpB+AAAAAldEVYdGRhdGU6Y3JlYXRl ADIwMjEtMDUtMTZUMTA6NTY6MTcrMDE6MDCh/kkpAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIxLTA1 LTE2VDA5OjU3OjA2KzAxOjAwTyZ6HwAAAABJRU5ErkJggg== MIME-Version: 1.0 Content-Type: text/plain List-ID: Precedence: bulk >>>>> Eric Abrahamsen writes: > On 09/06/21 19:16 PM, Stephen Berman wrote: >> 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 >> >> Debugger entered--Lisp error: (error "nndiary loaded") >> signal(error ("nndiary loaded")) error("nndiary loaded") >> eval-buffer(# 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(# 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) #) metadata) >> completion-metadata("gnus-extra-" help--symbol-completion-table >> #f(compiled-function (vv) #)) >> completion--field-metadata(20) completion--do-completion(20 31) >> completion--in-region-1(20 31) #f(compiled-function (start end >> collection predicate) # )(20 31 help--symbol-completion-table >> #f(compiled-function (vv) #)) >> apply(#f(compiled-function (start end collection predicate) >> #) (20 31 >> help--symbol-completion-table #f(compiled-function (vv) >> #))) #f(compiled-function (funs global >> args) # )(nil nil (20 31 help--symbol-completion-table >> #f(compiled-function (vv) #))) >> completion--in-region(20 31 help--symbol-completion-table >> #f(compiled-function (vv) #)) >> completion-in-region(20 31 help--symbol-completion-table >> #f(compiled-function (vv) #)) >> 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.