From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Possible defvar bug Date: Mon, 18 Feb 2013 08:40:50 -0800 Message-ID: <817CBEB96CCA4E6089A0BC2C4D642C49@us.oracle.com> References: <87d2vxr8h6.fsf@thinkpad.tsdh.de> <87obfhy8zc.fsf@gmail.com> <20130218150954.GA4583@acm.acm><8738wty6hz.fsf@gmail.com><340816FB6EB446BFBBCCCA6551E851E9@us.oracle.com> <87wqu5k2q3.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1361205676 24034 80.91.229.3 (18 Feb 2013 16:41:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Feb 2013 16:41:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Thierry Volpiatto'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 18 17:41:37 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U7TmY-0003z2-DC for ged-emacs-devel@m.gmane.org; Mon, 18 Feb 2013 17:41:34 +0100 Original-Received: from localhost ([::1]:44610 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7TmB-00064T-3t for ged-emacs-devel@m.gmane.org; Mon, 18 Feb 2013 11:41:11 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:47359) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7Tlz-00061h-J4 for emacs-devel@gnu.org; Mon, 18 Feb 2013 11:41:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U7Tlv-0003FT-A1 for emacs-devel@gnu.org; Mon, 18 Feb 2013 11:40:59 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:37357) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7Tlv-0003FA-47 for emacs-devel@gnu.org; Mon, 18 Feb 2013 11:40:55 -0500 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1IGeqfp003990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Feb 2013 16:40:52 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1IGep3b023736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2013 16:40:51 GMT Original-Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1IGeoUO015206; Mon, 18 Feb 2013 10:40:50 -0600 Original-Received: from dradamslap1 (/130.35.178.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 18 Feb 2013 08:40:50 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87wqu5k2q3.fsf@gmail.com> Thread-Index: Ac4N9L3uc3HTcFOxSfGfA7/WEvqCygAALYPg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:157138 Archived-At: > >> See also documentation of `require' which should not be used inside > >> `let' bindings for same reasons. > > > > Hm. What doc of `require' mentions this? > > ,---- > | (Note that it > | is important that the `require' statement be outside the body of the > | `let'. Loading a library while its variables are let-bound can have > | unintended consequences, namely the variables becoming unbound after > | the let exits.) > `---- Right, thanks - read right past that without noticing, somehow. > > I hope that the doc for this, wherever it might be, is more specific > > than what you said, because I cannot imagine that such a blanket > > statement is correct. Presumably, any potential problem would depend > > on what variables the `let' binds? > Of course. And the passage is clear enough about that: "the `let'" and "its variables" refer to a specific `let' that binds variables defined in the required file. That's the point. It's worth being careful about this - a general statement that "`require' should not be used inside `let' bindings" is quite misleading. You had me worried there, for a moment. Thanks for the doc reference.