|
From: | Daniel Colascione |
Subject: | bug#34114: 27.0.50: pdumper and themes with Emacs daemon |
Date: | Tue, 22 Jan 2019 17:41:34 -0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |