bug#34114: 27.0.50: pdumper and themes with Emacs daemon

[Eli Zaretskii]

> Cc: 34114@debbugs.gnu.org, kaushal.modi@gmail.com
> From: Daniel Colascione <dancol@dancol.org>
> Date: Mon, 21 Jan 2019 17:59:46 -0500
> 
> In general, we should try do as much work as possible in the initial 
> dump, just as we do in unexeced Emacs. Frames, however, are special 
> because we can't actually save and restore frames. Any frame object 
> comes back, after pdumper load, as an all-nil object.

What is special about frames that precludes them from being recorded
by the pdumper?  Since the startup code is written under the
assumption that a frame is available with some minimal functionality,
I'm afraid this face issue could be the tip of a large iceberg.  E.g.,
many customizations in users' .emacs files might stop working if we
don't have an initial frame like we had in unexeced version.

> All of this is very confusing and we should probably totally rethink
> it after we remove unexec.

I wholeheartedly agree.  Unexec was invented to record loaded Lisp
code, but with time it ended up accruing a lot of stuff that is only
tangentially related to Lisp, or even not at all.  However,
rearranging all that and removing all the cruft we no longer need is a
formidable job, so I think we should embark on that only after we have
a reliable baseline, a pdumper version that works as well as the
unexeced one.  And it will take us some time to find and fix any
remaining bugs and then become convinced that we've reached that goal.

So I'd like first to have a pdumper version that works as close to the
unexec version, and only after that start moving/removing the
initialization code from temacs to emacs.