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

[Eli Zaretskii]

On January 23, 2019 6:05:40 AM GMT+02:00, Daniel Colascione <dancol@dancol.org> 
wrote:
> 
> 
> 
> On Jan 22, 2019 7:43 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Cc: karl@karlotness.com, 34114@debbugs.gnu.org,
> kaushal.modi@gmail.com 
> > From: Daniel Colascione <dancol@dancol.org> 
> > Date: Tue, 22 Jan 2019 17:41:34 -0800 
> > 
> > > 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. 
> 
> Sorry, I still don't think I understand: what is that 
> instance-specific state, in terms of members of the frame object, or 
> its attributes? 
> 
> 
> A frame is always associated with a specific pty, specific X11 window,
> specific win32 window, etc. These concepts do not exist across
> different invocations of Emacs. I don't understand what you don't
> understand. 

I didn't understand what you meant by "instance".  I think I do now -- you mean 
output_method, output_data, and terminal members of struct frame?  If so, these 
are (trivially) figured out for the initial frame, they are set to special 
values.  And we delete that initial frame during startup, as soon as we can.  
So I don't think I understand the concerns.  What specific problems could be 
caused by retaining this initial frame?