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: defcustom standard value and byte-compilation Date: Tue, 10 Mar 2015 13:04:39 +0100 Message-ID: <87r3sxukh4.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1425989113 17899 80.91.229.3 (10 Mar 2015 12:05:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Mar 2015 12:05:13 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 10 13:05:05 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 1YVIuG-0000xt-B0 for ged-emacs-devel@m.gmane.org; Tue, 10 Mar 2015 13:05:04 +0100 Original-Received: from localhost ([::1]:48464 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVIuF-0002g8-KZ for ged-emacs-devel@m.gmane.org; Tue, 10 Mar 2015 08:05:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33232) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVIty-0002fz-Hs for emacs-devel@gnu.org; Tue, 10 Mar 2015 08:04:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YVItt-0001Cv-47 for emacs-devel@gnu.org; Tue, 10 Mar 2015 08:04:46 -0400 Original-Received: from deliver.uni-koblenz.de ([141.26.64.15]:45014) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVIts-0001Cf-UA for emacs-devel@gnu.org; Tue, 10 Mar 2015 08:04:41 -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 368CE1A83FD for ; Tue, 10 Mar 2015 13:04:40 +0100 (CET) Mail-Followup-To: emacs-devel@gnu.org 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:183765 Archived-At: Hi all, I just found out that the form defining the standard value of a defcustom is not subject to byte-compilation. 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. This is the concrete example in AUCTeX's tex.el: --8<---------------cut here---------------start------------->8--- (eval-when-compile (require 'cl)) (defcustom TeX-style-path (let ((path)) (mapc (lambda (file) (when file (pushnew file path))) (append (list TeX-auto-global TeX-style-global) TeX-auto-private TeX-style-private (list TeX-auto-local TeX-style-local))) (nreverse path)) ;; docs & keywords ) --8<---------------cut here---------------end--------------->8--- In the byte-compiled tex.elc, the reference to pushnew is still there and you get an error when loading tex.el and cl hasn't been required beforehand. I fixed this concrete situation by using `member' and `cons' instead of `pushnew' but IMHO this behavior is at the very least surprising. 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? Also, I don't find a note on that behavior in the docs. Bye, Tassilo