On Sat, Feb 18, 2023, 2:07 AM Eli Zaretskii <
eliz@gnu.org> wrote:
> 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.
I wrote about 95% of this over the weekend, most of which is the efficient solver for dependency ordering of the customization variables set at startup. I'll finish it up in the next couple of evenings and post the patch in a bug report/feature request.
My immediate concern is being able to use the current re-dumping facility more effectively.
Lynn