From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/64150 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: Wrong use of "path" in spam.el Date: Wed, 27 Dec 2006 14:24:12 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: References: NNTP-Posting-Host: dough.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1167247497 14789 80.91.229.10 (27 Dec 2006 19:24:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 27 Dec 2006 19:24:57 +0000 (UTC) Original-X-From: ding-owner+M12673=ding+2Daccount=gmane.org@lists.math.uh.edu Wed Dec 27 20:24:54 2006 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by dough.gmane.org with esmtp (Exim 4.50) id 1GzeOU-0006PP-BN for ding-account@gmane.org; Wed, 27 Dec 2006 20:24:54 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1GzeOT-0005nO-CB for ding-account@gmane.org; Wed, 27 Dec 2006 13:24:53 -0600 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1GzeOS-0005nJ-Fv for ding@lists.math.uh.edu; Wed, 27 Dec 2006 13:24:52 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.63) (envelope-from ) id 1GzeOM-0002nr-C5 for ding@lists.math.uh.edu; Wed, 27 Dec 2006 13:24:52 -0600 Original-Received: from fw01.cmbrmaks.akamai.com ([80.67.64.10] helo=smtp1.akamai.com) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1GzeOL-0006dD-00 for ; Wed, 27 Dec 2006 20:24:45 +0100 Original-Received: from smtp1.akamai.com (vwall.kendall.corp.akamai.com [172.17.4.33]) by smtp1.akamai.com (8.13.8/8.12.10) with ESMTP id kBRJNtkE016830 for ; Wed, 27 Dec 2006 14:23:55 -0500 (EST) Original-Received: from dhcp-65-162.kendall.corp.akamai.com (dhcp-65-165.kendall.corp.akamai.com [172.16.36.21]) by smtp1.akamai.com (8.13.8/8.12.10) with ESMTP id kBRJNswV016815 for ; Wed, 27 Dec 2006 14:23:54 -0500 (EST) Original-To: ding@gnus.org X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6;d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Followup-To: ding@gnus.org In-Reply-To: (Reiner Steib's message of "Wed\, 27 Dec 2006 17\:50\:34 +0100") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.91 (gnu/linux) X-Spam-Score: -2.5 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:64150 Archived-At: On 27 Dec 2006, reinersteib+gmane@imap.cc wrote: On Wed, Dec 27 2006, Ted Zlatanov wrote: > On 26 Dec 2006, reinersteib+gmane@imap.cc wrote: >>> [...] `spam-*-path' variables and doc strings. We should rename >>> those variables to `spam-*-program' and mark the former as obsolete. >>> >>> I'm not 100% sure that it's a good idea to do this now (while Emacs 22 >>> is in pretest), but OTOH spam.el was not part of Emacs 21 so it's >>> probably better to do it now so that Emacs 22 will have the right >>> names. Opinions? >> >> I'm OK with that. Since the old variable names will work today, I >> expect the support issues to be minimal. > > Maybe we should better use `defvaralias' instead of > `make-obsolete-variable'? I wasn't sure which one is more suitable > here. I'm OK with either; I don't know the right one though. >> But the manual will also have to be updated, > > AFAICS, it's only the following change (installed in v5-10): > --- gnus.texi 26 Dec 2006 19:10:32 +0100 6.603.2.107 > +++ gnus.texi 27 Dec 2006 17:38:39 +0100 > @@ -23952,7 +23952,7 @@ > the default value of @samp{spam}. > @end defvar > > -@defvar spam-ifile-database-path > +@defvar spam-ifile-database > > This is the filename for the ifile database. It is not specified by > default, so ifile will use its own default database name. OK, I thought there were more. Sorry. >> and we need to check with the Emacs maintainers regarding the 22 >> prerelease. > > The changes will automatically be included in the next pretest after > Miles next sync. Do you have something else in mind? That was all, I didn't know if we need to ask before making such changes since they are not really bug fixes. Ted