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

[Daniel Colascione <dancol@dancol.org>]

On 1/22/19 8:45 AM, Eli Zaretskii wrote:
>> 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?

Frames contain instance-specific state, and I don't think it makes sense 
to try to pretend that individual frames survive from one Emacs 
invocation to another. We definitely want to record customizations that 
affect frames generally (like face definitions), but IMHO, we should do 
that in a way that doesn't depend on preserving any frame in particular.

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

We do have an initial frame: we just make it anew when we start Emacs. 
When we set a face attribute, we set it for new frames as well by 
calling Finternal_set_lisp_face_attribute with frame being Qt, which 
ends up updating face-new-frame-defaults, which we do preserve in a 
pdumped image. If these defaults aren't being applied to frames we 
create after pdumper load, there's a bug.