OK, lots of things to react to.

> Not defining `custom-file' _would_ change the
> behavior.  Setting `custom-file' to your init
> file would keep the current default behavior of
> Customize using your init file.

IMHO, that's a bit more disruptive (Po Lu, you made me think about that ;-) )...
And using the NEWS to explain the change might have people getting mad.

My approach, as detailed above. might be less "aggressive", right? Wouldn't be people happier with it?
Like in "I didn't say anything about custom-file, so if I don't, nothing changes"
Then they can eventually set custom-file to "~/.emacs.d/custom.el" to migrate (NEWS might be a nice place to advertise this)

With that I'd be more than happy, because I would be able to define my OS specific custom-file and have it loaded.

> Why byte-compile your init file?
That was something I wasn't thinking about. I never byte-compiled my init file, nor would I think that custom-file should be byte-compiled either :-)

/PA

On Wed, 5 Jan 2022 at 10:35, Po Lu <luangruo@yahoo.com> wrote:
LdBeth <andpuke@foxmail.com> writes:

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

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

Thanks.


--
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler