From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.ciao.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.bugs Subject: bug#34114: 27.0.50: pdumper and themes with Emacs daemon Date: Mon, 21 Jan 2019 17:59:46 -0500 Message-ID: <8604635d-af06-4ce6-320e-4f145c11bc37@dancol.org> References: <83va2lazzn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.org; posting-host="ciao.gmane.org:195.159.176.228"; logging-data="66773"; mail-complaints-to="usenet@ciao.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 Cc: 34114@debbugs.gnu.org, kaushal.modi@gmail.com To: Eli Zaretskii , Karl Otness Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jan 22 00:16:31 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1glins-000HG7-Kr for geb-bug-gnu-emacs@m.gmane.org; Tue, 22 Jan 2019 00:16:28 +0100 Original-Received: from localhost ([127.0.0.1]:35781 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glinr-0002iX-Fp for geb-bug-gnu-emacs@m.gmane.org; Mon, 21 Jan 2019 18:16:27 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:46060) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glinf-0002dN-9z for bug-gnu-emacs@gnu.org; Mon, 21 Jan 2019 18:16:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gliY0-0001mF-35 for bug-gnu-emacs@gnu.org; Mon, 21 Jan 2019 18:00:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41356) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gliXz-0001lv-Uj for bug-gnu-emacs@gnu.org; Mon, 21 Jan 2019 18:00:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gliXz-0004hG-NM for bug-gnu-emacs@gnu.org; Mon, 21 Jan 2019 18:00:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Jan 2019 23:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34114 X-GNU-PR-Package: emacs Original-Received: via spool by 34114-submit@debbugs.gnu.org id=B34114.154811160018014 (code B ref 34114); Mon, 21 Jan 2019 23:00:02 +0000 Original-Received: (at 34114) by debbugs.gnu.org; 21 Jan 2019 23:00:00 +0000 Original-Received: from localhost ([127.0.0.1]:40637 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gliXw-0004gU-7y for submit@debbugs.gnu.org; Mon, 21 Jan 2019 18:00:00 -0500 Original-Received: from dancol.org ([96.126.100.184]:37610) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gliXs-0004gI-4Z for 34114@debbugs.gnu.org; Mon, 21 Jan 2019 17:59:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=N9sP/gu0zIsBsZHE9M3QSlfA9pqJkcV5wpcOF6pbbPo=; b=jC1npAsSb5yt5DAX9v6Vnhc6EyfDYT/JKBlmaiGEP+JcQ6ijZGCZKQFfdrhZSwNfRl7EqtAEG3qsDVrazdcB31RmkWH2i6JQ57YrRa/t+zp3ARE1MplQ/aUvdkHr4fr6zOU0M3aA4XxudOy26HWtPRTxVilnOBsh3L7NzUp+5sK4zFlgNK4q+EF+7IKqKw6JFkX5w1JNmtHappA4tAgQNDUTcMUn2DH201nafc2b3NaAVT5lbnaQUIz5Xy3OkaB9HrrPoJt3JDhaTpnJ0SWgI/6nkvfLr3ZcVfGokeENY5jc7TrTeBCWqKqfrRMs71BJfN3B2Npl8ZtePJmrphWskg==; Original-Received: from [2604:4080:1321:9a00:281a:fe2d:5d87:d563] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1gliXp-00070e-QC; Mon, 21 Jan 2019 14:59:53 -0800 In-Reply-To: <83va2lazzn.fsf@gnu.org> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:154669 Archived-At: On 1/19/19 2:05 AM, Eli Zaretskii wrote: >> From: Karl Otness >> Date: Fri, 18 Jan 2019 23:02:14 +0000 >> Cc: Kaushal Modi >> >> I think I have found a change that fixes this issue. I haven't tested >> it too thoroughly, but it seems to work for me. The change is to call >> init_faces_initial from init_display_interactive even when Emacs is >> running as daemon. >> >> In init_display_interactive in dispnew.c moving the lines: >> >>> /* Set up faces of the initial terminal frame. */ >>> if (!noninteractive && NILP (Vinitial_window_system)) >>> init_faces_initial (); >> >> from the end of the function so that they occur before the early >> return in the IS_DAEMON check (around line 6039) seems to fix the >> theme loading problem. > > Thanks for identifying the code that's involved in this. > > However, I'm not yet sure the solution you propose is the correct > one. The way the code is written, it relies on the faces of the > initial frame to be initialized when Emacs is built, and then recorded > in the dumped Emacs. With the pdumper approach, the record should be > in the emacs.pdmp file, and I'd expect it to be restored from there. > > Why isn't this working? > > If we want to repeat this initialization in the daemon when it starts > up, I'd like first to better understand the considerations for this > kind of situations: when we should fix such problems by recording and > restoring them to/from the dump file, and when we should run the > initialization code anew in the dumped Emacs. The latter might mean > we cause more trouble elsewhere, because a lot of the code that runs > during startup expects stuff done in temacs to be available and ready > to use, not recomputed anew. > > Daniel, can you comment on this aspect of the problem, including on > the more general issue? > > In any case, if the proposed change is installed, it should not affect > the unexeced Emacs, so it IMO should be conditioned on > dumped_with_pdumper_p. Unexeced Emacs should continue behaving as it > did before. 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. Since faces are attached to frames, and since after pdumper load, we have all-new frames, we need to re-add the default faces. Kaushal's change seems like the right sort of fix. All of this is very confusing and we should probably totally rethink it after we remove unexec.