Re: Regression in dump-emacs-portable

[Eli Zaretskii]

> From: Lynn Winebarger <owinebar@gmail.com>
> Date: Fri, 17 Feb 2023 18:44:18 -0500
> Cc: emacs-devel@gnu.org
> 
> On Fri, Feb 17, 2023 at 9:31 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > I don't understand what will this solve.  Why does it matter when
> > exactly is a variable initialized, if in any case that will happen
> > before re-dumping?
> 
> You're right with respect to the current definitions of
> custom-initialize-* functions that will only set variables if they are
> unbound.
> The docstring for custom-initialize-delay is:
>   "Delay initialization of SYMBOL to the next Emacs start.
> This is used in files that are preloaded (or for autoloaded
> variables), so that the initialization is done in the run-time
> context rather than the build-time context.  This also has the
> side-effect that the (delayed) initialization is performed with
> the :set function."
> But "so the initialization is done in the run-time context" and "to
> the *next* Emacs start" (emphasis mine) are contradictory unless
> dumping can only happen once.    The first sentence should be "Ensure
> SYMBOL is set to initial-value at Emacs startup".

temacs and bootstrap-emacs (and in general any Emacs that is about to
dump itself) also start up, so the change you propose will make the
doc string less accurate.

> I'll take a shot at a more thorough rewrite of the customization
> system to properly support redumping this weekend and send another
> patch.

I'm not sure this is the tree we should be barking up.  The problem is
more general than just delayed-initialization of some defcustoms.