Re: Regression in dump-emacs-portable

[Lynn Winebarger <owinebar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3162 bytes --]