From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/80462 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: problem with gnus-group-make-nnir-group Date: Mon, 31 Oct 2011 20:54:14 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87ipn4slvt.fsf@lifelogs.com> References: <877h3ub3nc.fsf@micropit.couberia.bzh> <87ipndr6cd.fsf@micropit.couberia.bzh> <87lis6cp4l.fsf@lifelogs.com> <87d3delbch.fsf@micropit.couberia.bzh> <87ehxue23n.fsf@gnu.org> <87lis1t6xz.fsf@lifelogs.com> <8762j4d8wr.fsf@gnu.org> Reply-To: ding@gnus.org NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1320108881 9313 80.91.229.12 (1 Nov 2011 00:54:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 1 Nov 2011 00:54:41 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M28747=ding+2Daccount=gmane.org@lists.math.uh.edu Tue Nov 01 01:54:37 2011 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RL2cb-0005jM-NR for ding-account@gmane.org; Tue, 01 Nov 2011 01:54:34 +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 1RL2ca-00020H-RU for ding-account@gmane.org; Mon, 31 Oct 2011 19:54:32 -0500 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 1RL2cZ-00020B-Dn for ding@lists.math.uh.edu; Mon, 31 Oct 2011 19:54:31 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RL2cX-0007fm-UW for ding@lists.math.uh.edu; Mon, 31 Oct 2011 19:54:30 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1RL2cV-0007dY-UG for ding@gnus.org; Tue, 01 Nov 2011 01:54:27 +0100 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RL2cV-0005fm-Od for ding@gnus.org; Tue, 01 Nov 2011 01:54:27 +0100 Original-Received: from c-76-28-40-19.hsd1.vt.comcast.net ([76.28.40.19]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Nov 2011 01:54:27 +0100 Original-Received: from tzz by c-76-28-40-19.hsd1.vt.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Nov 2011 01:54:27 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: ding@gnus.org Original-Lines: 32 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: c-76-28-40-19.hsd1.vt.comcast.net 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-Copies-To: never User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux) Cancel-Lock: sha1:LU9ZlTbMhR3TvucpaxCEUw+J0Qs= X-Spam-Score: -6.1 (------) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:80462 Archived-At: On Tue, 01 Nov 2011 01:01:41 +0100 "Jose A. Ortega Ruiz" wrote: >> I don't know how that's possible. nnir.el has >> >> (defvar gnus-registry-enabled) jao> The variable is declared, but still unbound: trying to use it will raise jao> an error (because it has no value). Normally yes, but `gnus-bound-and-true-p' is a macro whose entire reason for existence is to avoid that situation. How annoying. >> and loads gnus-util.el, which defines `gnus-bound-and-true-p'. jao> This is a macro defined inside an eval-when-compile: the packaged Emacs jao> comes with a compiled version (gnus-util.elc), and it's the compiled jao> file that gets loaded when (require 'gnus-util) is called. The idiom of jao> wrapping macros in an eval-when-compile form is intended for macros that jao> are going to be used in the same file that defines them. Thanks for explaining. Yeah, I see the problem and was kind of figuring it out myself gradually but you've made it clear :) I think, then, that simply taking that macro out of the `eval-when-compile' should be enough. But I brought that macro out of retirement and it's only used by me in situations where performance does not matter. So I think it's OK to just go with the `gnus-bound-and-true-dumber-p' version I just committed and get rid of the original macro. WDYT? Thanks Ted