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: defcustom standard value and byte-compilation Date: Wed, 11 Mar 2015 08:18:24 +0100 Message-ID: <8761a8rohr.fsf@gnu.org> References: <87r3sxukh4.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1426058334 25539 80.91.229.3 (11 Mar 2015 07:18:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Mar 2015 07:18:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 11 08:18:45 2015 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 1YVauj-0002mz-7j for ged-emacs-devel@m.gmane.org; Wed, 11 Mar 2015 08:18:45 +0100 Original-Received: from localhost ([::1]:53006 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVauh-0007Og-Kd for ged-emacs-devel@m.gmane.org; Wed, 11 Mar 2015 03:18:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54269) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVauU-0007Ob-Bm for emacs-devel@gnu.org; Wed, 11 Mar 2015 03:18:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YVauQ-0004pX-7t for emacs-devel@gnu.org; Wed, 11 Mar 2015 03:18:30 -0400 Original-Received: from deliver.uni-koblenz.de ([141.26.64.15]:58258) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVauQ-0004pP-1t for emacs-devel@gnu.org; Wed, 11 Mar 2015 03:18:26 -0400 Original-Received: from thinkpad-t440p (dhcp27.uni-koblenz.de [141.26.71.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id 4A5841A8468; Wed, 11 Mar 2015 08:18:25 +0100 (CET) Mail-Followup-To: Stefan Monnier , emacs-devel@gnu.org In-Reply-To: (Stefan Monnier's message of "Tue, 10 Mar 2015 20:46:57 -0400") User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.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:183781 Archived-At: Stefan Monnier writes: >> I just found out that the form defining the standard value of a >> defcustom is not subject to byte-compilation. > > IIRC this is not the case if you use lexical-binding. I don't think this is an option for AUCTeX as it supports Emacs versions down to 21.4 and also XEmacs. And several parts make use of the dynamic binding of locals. :-( >> The problem with that is that you can't use macros in there without >> having to require the file providing the macro at load-time, too. > > Indeed, and the byte-compiler won't warn about unknown functions/vars > and things like that. > >> I can use macros in functions and init-forms of defvars and defconsts >> and they are all compiled away, so why shouldn't I allowed to do the >> same for defcustoms? > > IIIRC there's a pending bug report about the new behavior in > lexical-binding mode, because when you M-x customize-variable and ask > to see the expression it shows you the byte-compiled gobbledygook > instead of a readable expression. But customize shows the value of the expression, not the expression itself. So in my case the value is a list of strings which should not be different no matter if it has been computed by a byte-compiled expression or a non-b-c'ed expression. Ah, I think I got it. The difference is when the standard expression computes a value which can be byte-compiled, e.g., a function. If the standard expression is byte-compiled, it'll result in a byte-compiled function which is not readable anymore. Ok, but couldn't the standard form be at least macroexpanded? That shouldn't cause any harm and would take care of the typical use-case where one uses macros of a package which might not be available at load-time. >> Also, I don't find a note on that behavior in the docs. > > I don't think it was a conscious decision. Probably. And at least it's consistent with older Emacs versions and XEmacs. Bye, Tassilo