Re: Regression in dump-emacs-portable

[Lynn Winebarger]

On Thu, Feb 16, 2023 at 10:34 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Lynn Winebarger <owinebar@gmail.com>
> > Date: Thu, 16 Feb 2023 10:05:00 -0500
> > Cc: emacs-devel <emacs-devel@gnu.org>
> >
> > I do see something in the redumped emacs that seems like a bug to me.  The 
> > process I use for creating the
> > dump uses the -Q flag.  But some of the settings I see in "emacs -Q 
> > --dump-file ..." are not the ones I see
> > with just "emacs -Q".  Some are pretty basic - menu-bar-mode, 
> > tool-bar-mode, global-font-lock-mode,
> > transient-mark-mode are all nil in the redumped process but not the 
> > baseline.
>
> That is exactly the problem with re-dumping: stuff that was
> initialized on the first start gets dumped, and then works differently
> when Emacs is restarted from the second dump.

That appears to be a consequence of setting
custom-delayed-init-variables to t in startup, without saving a copy
to be restored by an after-pdump-load-hook.  Those modes have an
init-value expression involving "(not noninteractive)"  that is
evaluated during batch mode startup but not in the post-redump
startup.

> Figuring this out is the main part of the job of enabling re-dumping.
>
re-dumping in 28.2 works well enough to be useful.  At least I can
explicitly set the custom-delayed-init-variables by setting a hook,
and various kludges to make things work.
 The dump procedure just failing in 29/30 is much more problematic for
me.  I only mentioned the failures with the libraries included in
emacs, but libraries from packages that previously dumped just fine
also fail.  Starting up with 2200 loaded libraries is much faster
after redumping in 28.2.

> > A general test would be load the additional files to be dumped, write out 
> > all the symbol properties, variable
> > values, and function values, then load the dump file and compare everything 
> > with equal, including the set of
> > symbols, variables and functions defined.
> > Is it fair to say that is the correct expectation of the dumping procedure?
>
> I don't think this will work, because at least the defcustoms are
> evaluated upon each startup, and a defcustom can have a setter
> function.  And there are probably more features which will get in the
> way.
I suppose there are two versions of this test.  One is, what is the
correct behavior, and has it been achieved?  The regression version
is,  is the current behavior no more incorrect than the reference
version, i.e. correct for all elements of the lisp heap for which the
reference version is correct?

Lynn