[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: defcustom standard value and byte-compilation

From: Tassilo Horn
Subject: Re: defcustom standard value and byte-compilation
Date: Wed, 11 Mar 2015 08:18:24 +0100
User-agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux)

Stefan Monnier <address@hidden> 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

>> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]