From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/50656 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: convert from setq to customization Date: Fri, 07 Mar 2003 19:38:42 +0100 Sender: owner-ding@hpc.uh.edu Message-ID: References: <86u1em4wdn.fsf@red.stonehenge.com> <4nadg9fsw2.fsf@lockgroove.bwh.harvard.edu> <4nof4o2xc1.fsf@lockgroove.bwh.harvard.edu> <4nzno7w3nf.fsf@lockgroove.bwh.harvard.edu> <4nwujbulmk.fsf@lockgroove.bwh.harvard.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1047062347 3562 80.91.224.249 (7 Mar 2003 18:39:07 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 7 Mar 2003 18:39:07 +0000 (UTC) Original-X-From: owner-ding@hpc.uh.edu Fri Mar 07 19:39:06 2003 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18rMkM-0000vI-00 for ; Fri, 07 Mar 2003 19:39:06 +0100 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 18rMkM-0005vl-00; Fri, 07 Mar 2003 12:39:06 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 07 Mar 2003 12:40:05 -0600 (CST) Original-Received: from sclp3.sclp.com (sclp3.sclp.com [66.230.238.2]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id MAA09724 for ; Fri, 7 Mar 2003 12:39:51 -0600 (CST) Original-Received: (qmail 41560 invoked by alias); 7 Mar 2003 18:38:47 -0000 Original-Received: (qmail 41555 invoked from network); 7 Mar 2003 18:38:46 -0000 Original-Received: from 178.230.13.217.in-addr.dgcsystems.net (HELO yxa.extundo.com) (217.13.230.178) by 66.230.238.6 with SMTP; 7 Mar 2003 18:38:46 -0000 Original-Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.8/8.12.8) with ESMTP id h27IcgdD027254 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 7 Mar 2003 19:38:44 +0100 Original-To: ding@gnus.org Mail-Copies-To: nobody X-Payment: hashcash 1.2 0:030307:ding@gnus.org:981ce6135a5de9db X-Hashcash: 0:030307:ding@gnus.org:981ce6135a5de9db In-Reply-To: <4nwujbulmk.fsf@lockgroove.bwh.harvard.edu> (Ted Zlatanov's message of "Fri, 07 Mar 2003 12:33:55 -0500") User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/21.3.50 (gnu/linux) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:50656 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:50656 Ted Zlatanov writes: > On Fri, 07 Mar 2003, jas@extundo.com wrote: >> Yes, an error seems too much. Using a separate, non-customized, >> nnimap variable that spam.el can set seems like a better approach, >> and this approach is used in similar situations already. It would >> also allow people to set n-s-d-b to override the spam.el decision, >> if they wanted that. > > OK with me, let me know when you have that in place. Done, use n-s-d-b-default instead. (defvar nnimap-split-download-body-default nil "Internal variable with default value for `nnimap-split-download-body'.") (defcustom nnimap-split-download-body 'default "Whether to download entire articles during splitting. This is generally not required, and will slow things down considerably. You may need it if you want to use an advanced splitting function that analyses the body before splitting the article. If this variable is nil, bodies will not be downloaded; if this variable is the symbol `default' the default behaviour is used (which currently is nil, unless you use a statistical spam.el test); if this variable is another non-nil value bodies will be downloaded." :group 'nnimap :type '(choice (const :tag "Let system decide" deault) boolean)) > Also I have to load nnimap.el to avoid the > > ** assignment to free variable nnimap-split-download-body > > error (I will get it with nnimap-using-spam as well, surely) - is > there something I can do without loading nnimap, maybe an autoloaded > function? I don't want to load nnimap needlessly, and I don't want to > override gnus-get-new-news with a wrapper that does a lexical > let. > > There's no way to know that nnimap is needed by the user at any point! > Should I just load nnimap and live with the shame? :) No, add (defvar nnimap-split-download-body) to spam.el. Or (eval-when-compile (require 'nnimap)). Or we can put an autoload cookie on n-s-d-b-d.