bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#34114: 27.0.50: pdumper and themes with Emacs daemon
Date: Wed, 23 Jan 2019 07:32:25 +0200
User-agent: K-9 Mail for Android

On January 23, 2019 6:05:40 AM GMT+02:00, Daniel Colascione <address@hidden> 
wrote:
> 
> 
> 
> On Jan 22, 2019 7:43 PM, Eli Zaretskii <address@hidden> wrote:
> 
> > Cc: address@hidden, address@hidden,
> address@hidden 
> > From: Daniel Colascione <address@hidden> 
> > 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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]