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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 22 Jan 2019 22:48:59 -0800
> From: Daniel Colascione <dancol@dancol.org>
> Cc: karl@karlotness.com, 34114@debbugs.gnu.org, kaushal.modi@gmail.com
> 
> We'd still need code to serialize frames. And for what? What would we get with this scheme?

Smoother transition, perhaps?

Anyway, I've compared the values of some important members of 'struct
frame' after restoring from pdump, and didn't see any other problems.
So Karl, could you please try the patch below, which is based on your
idea, but with a quirk?

And before you apply the patch, could you perhaps show C and Lisp
backtraces from the errors you were seeing?  I don't see those errors
here when I try your recipe, and I'd like to better understand where
the problem happens.

Thanks.

diff --git a/src/dispnew.c b/src/dispnew.c
index 88783cd..1cafe29 100644
--- a/src/dispnew.c
+++ b/src/dispnew.c
@@ -6037,7 +6037,18 @@ init_display_interactive (void)
      except on Windows, where we at least want to initialize it.  */
 #ifndef WINDOWSNT
   if (IS_DAEMON)
+    {
+      /* Pdump'ed Emacs doesn't record the initial frame from temacs,
+	 so the non-basic faces realized for that frame in temacs
+	 aren't in emacs.  This causes errors when users try to
+	 customize those faces in their init file.  The call to
+	 init_faces_initial will realize these faces now.  (Non-daemon
+	 Emacs does this either near the end of this function or when
+	 the GUI frame is created.)  */
+      if (dumped_with_pdumper_p ())
+        init_faces_initial ();
       return;
+    }
 #endif
 
   /* If the user wants to use a window system, we shouldn't bother