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

[Daniel Colascione]

On Jan 22, 2019 9:32 PM, Eli Zaretskii <eliz@gnu.org> wrote:

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? 

We'd still need code to serialize frames. And for what? What would we get with this scheme?