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,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5803 invoked from network); 6 Sep 2021 18:40:19 -0000 Received: from mx1.math.uh.edu (129.7.128.32) by inbox.vuxu.org with ESMTPUTF8; 6 Sep 2021 18:40:19 -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 1mNJXV-00GCUG-NX for ml@inbox.vuxu.org; Mon, 06 Sep 2021 13:40:17 -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 1mNJXV-002KpG-1v for ml@inbox.vuxu.org; Mon, 06 Sep 2021 13:40:17 -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 1mNJXS-002Kp8-NV for ding@lists.math.uh.edu; Mon, 06 Sep 2021 13:40:14 -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 1mNJXQ-006ZDz-6Q for ding@lists.math.uh.edu; Mon, 06 Sep 2021 13:40:14 -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=EDzs0l1fXIqmbmnK4rLNxQKAbDKPfBMA6hB6sf7BZJ0=; b=jvOs/mvSmc03JQBqzG4ermj9tc vrdewqa1b0jrk8cNn1cAs0sdYG60ARiTzVhBySsgUjA9PjaKdCk07MUD+usCldTzBixMIehUGE3BM DbCCHpsdzMVXFHh/MMUgnjIQdHTe+5P4/xozDFpbQPZ15v86Bg9r77tgqukLcoi6rwyw=; Received: from mail.ericabrahamsen.net ([52.70.2.18]) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mNJXI-0004gB-3r for ding@gnus.org; Mon, 06 Sep 2021 20:40:08 +0200 Received: from localhost (24-113-148-110.wavecable.com [24.113.148.110]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id 8457BFA014; Mon, 6 Sep 2021 18:40:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericabrahamsen.net; s=mail; t=1630953601; bh=EDzs0l1fXIqmbmnK4rLNxQKAbDKPfBMA6hB6sf7BZJ0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=zcTjZ2ZKp2qheDIjUXXTgcppJnKJuNiOr4bkssKuveR4BQz41jDqz6ajRhWt2jTKD Qv6xntiIAt5XrAWVHATFqpv+YcakExPdBn+FzLk/CirQbYS1w0tPbOiSuurLZMeFBe NM7TyTJ7BkOXFGKjFn6VaC/wAEeXJkV8lf+nkqXE= From: Eric Abrahamsen To: Stephen Berman Cc: Colin Baxter , ding@gnus.org 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> Date: Mon, 06 Sep 2021 11:40:00 -0700 In-Reply-To: <87zgsppquh.fsf@rub.de> (Stephen Berman's message of "Mon, 06 Sep 2021 19:16:06 +0200") Message-ID: <877dftim4f.fsf@ericabrahamsen.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain List-ID: Precedence: bulk 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