From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: Possible defvar bug Date: Wed, 20 Feb 2013 09:09:02 +0100 Message-ID: <87liajxv8h.fsf@thinkpad.tsdh.de> References: <87d2vxr8h6.fsf@thinkpad.tsdh.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1361347757 29560 80.91.229.3 (20 Feb 2013 08:09:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Feb 2013 08:09:17 +0000 (UTC) Cc: Richard Stallman , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 20 09:09:39 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 1U84kE-0006op-WC for ged-emacs-devel@m.gmane.org; Wed, 20 Feb 2013 09:09:39 +0100 Original-Received: from localhost ([::1]:55333 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U84ju-0006PN-BQ for ged-emacs-devel@m.gmane.org; Wed, 20 Feb 2013 03:09:18 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:48527) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U84jm-0006OY-SC for emacs-devel@gnu.org; Wed, 20 Feb 2013 03:09:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U84jh-0006fQ-Ns for emacs-devel@gnu.org; Wed, 20 Feb 2013 03:09:10 -0500 Original-Received: from deliver.uni-koblenz.de ([141.26.64.15]:49286) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U84jh-0006fH-Hb; Wed, 20 Feb 2013 03:09:05 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by deliver.uni-koblenz.de (Postfix) with ESMTP id 29B791A8445; Wed, 20 Feb 2013 09:09:04 +0100 (CET) X-Virus-Scanned: amavisd-new at uni-koblenz.de Original-Received: from deliver.uni-koblenz.de ([127.0.0.1]) by localhost (deliver.uni-koblenz.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ly74qE_zws4; Wed, 20 Feb 2013 09:09:03 +0100 (CET) X-CHKRCPT: Envelopesender noch tsdh@gnu.org Original-Received: from thinkpad.tsdh.de (tsdh.uni-koblenz.de [141.26.67.142]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id BD6451A842A; Wed, 20 Feb 2013 09:09:03 +0100 (CET) Mail-Followup-To: Stefan Monnier , Richard Stallman , emacs-devel@gnu.org In-Reply-To: (Stefan Monnier's message of "Tue, 19 Feb 2013 19:08:49 -0500") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 141.26.64.15 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:157191 Archived-At: Stefan Monnier writes: > Another option is to change defvar so that it changes the specpdl > entry when the var is let-bound (i.e. so that the default is set when > we leave the let, as if it had been set before). That would be fine with me if it would apply not only to `defvar' but also to `defcustom'. The reason for the problematic code in AUCTeX was that the loading of crm should be deferred up to the point when it's actually used, e.g., when just viewing some LaTeX file there's no need to have crm loaded. Thus, it was required only in some lower-level completion function that's actually using it, but some of its higher-level (indirect) callers let-bound crm-separator as they needed. The alternative is to require crm at any caller binding `crm-separator', or to eagerly require it top-level. I do the latter now, and with crm which is rather small and doesn't require anything else, that's no big deal, but there are probably other packages where let-binding a variable makes sense and requiring the package triggers a cascading load of other packages. Bye, Tassilo