Re: defcustom standard value and byte-compilation

[Tassilo Horn]

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