Re: Regression in dump-emacs-portable

[Eli Zaretskii <eliz@gnu.org>]

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

It might sound like a minor issue, but it is actually a tip of a very
large iceberg.  When we run temacs to produce the dump file, we jump
through many hoops to avoid these problems, and then when dumped Emacs
is started, it jumps through some more hoops.  Those are all the
init_FOO_once and pdumper_do_now_and_after_load calls.  All this works
differently when Emacs starts from a re-dumped dump file.  For
example, features that are toggled might be turned off in the second
start because the startup code assumes they are originally turned off
and toggling them turns them on.

Figuring this out is the main part of the job of enabling re-dumping.

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