[Top][All Lists]

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

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

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: address@hidden, address@hidden
From: Daniel Colascione <address@hidden>
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.

reply via email to

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