GNU bug report logs - #34114
27.0.50: pdumper and themes with Emacs daemon

Previous Next

Package: emacs;

Reported by: Karl Otness <karl <at> karlotness.com>

Date: Thu, 17 Jan 2019 11:17:01 UTC

Severity: normal

Found in version 27.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #41 received at 34114 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34114 <at> debbugs.gnu.org, karl <at> karlotness.com, kaushal.modi <at> gmail.com
Subject: Re: bug#34114: 27.0.50: pdumper and themes with Emacs daemon
Date: Tue, 22 Jan 2019 17:41:34 -0800
On 1/22/19 8:45 AM, Eli Zaretskii wrote:
>> Cc: 34114 <at> debbugs.gnu.org, kaushal.modi <at> gmail.com
>> From: Daniel Colascione <dancol <at> 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.




This bug report was last modified 6 years and 116 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.