> I don't understand what's so bad about the third line that warrants
> loading the custom file by default.

If there's something bad, I missed it. It's been in my init.el for ages ;-)

However, providing for emacs to do it might help people separate init.el from custom.el which I think is good

And making sure it is loaded by default after init.el may help debugging, right? I mean, you know when the customisations

were loaded, and that may be more than what we have today, right?

> So I'm not sure we should make that easier, because it makes easier
> for people to make mistakes like that.

I don't think this helps people byte-compiling anything ;-)

On Wed, 5 Jan 2022 at 14:06, Eli Zaretskii <eliz@gnu.org> wrote:

> Date: Wed, 05 Jan 2022 17:17:12 +0800
> From: LdBeth <andpuke@foxmail.com>
> Cc: Drew Adams <drew.adams@oracle.com>,
> Pedro Andres Aranda Gutierrez <paaguti@gmail.com>,
> Robert Pluim
> <rpluim@gmail.com>,
> Eli Zaretskii <eliz@gnu.org>,
> Stefan Kangas
> <stefankangas@gmail.com>,
> "emacs-devel@gnu.org" <emacs-devel@gnu.org>
>
> >>>>> In <87bl0q8vfa.fsf@yahoo.com>
> >>>>> Po Lu <luangruo@yahoo.com> wrote:
>
> > Most people were certainly happy for at least the past decade.
>
> I think saving custom set variables to init file somehow prevents
> using byte compiled init.el file effectively (unless the user hooks
> auto compile whenever it is changed by emacs). From that perspective,
> I'm happy to see that this behavior is to be changed.

Byte compiling init.el is not a very good idea; natively-compiling
them is an even worse idea.

So I'm not sure we should make that easier, because it makes easier
for people to make mistakes like that.

Fragen sind nicht da um beantwortet zu werden,

Fragen sind da um gestellt zu werden

Georg Kreisler