Re: [External] : Re: Default custom file was: Re: Propose to add setup-wizard.el to ELPA

[LdBeth]

>>>>> In <8735m28qzr.fsf@yahoo.com> 
>>>>>   Po Lu <luangruo@yahoo.com> wrote:

ldb> I think saving custom set variables to init file somehow prevents
ldb> using byte compiled init.el file effectively (unless the user
ldb> hooks auto compile whenever it is changed by emacs). From that
ldb> perspective, I'm happy to see that this behavior is to be
ldb> changed.

PL> Why byte-compile your init file?  It usually makes no measurable
PL> difference whatsoever, except it breaks things like
PL> custom-set-variables and inhibit-startup-echo-area-message.

PL> Thanks.

In case heavy macros like `use-package' are used in the init file, and
by taking advantages of `eval-when-compile' a lot, byte-compiled init
file does make some difference.

I can't tell if writing custom-set-variables to init file by default
has made many people prefer a structured hierarchy instead of a single
init.el file. Having a single well debugged .emacs.elc been copied
across instances could be a choice.

Occasionally I see people using one Org-mode file to generate their
Emacs config files#1#, that's another kind of over engineering.

> inhibit-startup-echo-area-message

That's a hack :-) And the docstring already tells us a hackish
workaround:

> If your init file is byte-compiled, use the following form
> instead:
> (eval '(setq inhibit-startup-echo-area-message "YOUR-USER-NAME"))

And I would not get very disappointed by either way, because I've
already went with a structured config directory.

-- 
LDB

#1#=(I trend to not make judgment on the usefulness of Literate
Programming, but it is certainly meaningless to use it on something
that nobody else would read)