From mboxrd@z Thu Jan 1 00:00:00 1970
Path: news.gmane.org!not-for-mail
From: Paul Moore
Newsgroups: gmane.emacs.bugs
Subject: bug#23689: Daemon-mode on Windows - "w32-initialized" is set too early
Date: Wed, 8 Jun 2016 14:57:49 +0100
Message-ID:
References:
<8337otw9m0.fsf@gnu.org>
<83shwtusoj.fsf@gnu.org>
<83porxuhfo.fsf@gnu.org>
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
X-Trace: ger.gmane.org 1465396598 26048 80.91.229.3 (8 Jun 2016 14:36:38 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Wed, 8 Jun 2016 14:36:38 +0000 (UTC)
Cc: 23689@debbugs.gnu.org
To: Eli Zaretskii
Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jun 08 16:36:32 2016
Return-path:
Envelope-to: geb-bug-gnu-emacs@m.gmane.org
Original-Received: from lists.gnu.org ([208.118.235.17])
by plane.gmane.org with esmtp (Exim 4.69)
(envelope-from )
id 1bAeap-0001Ge-Bg
for geb-bug-gnu-emacs@m.gmane.org; Wed, 08 Jun 2016 16:36:27 +0200
Original-Received: from localhost ([::1]:57398 helo=lists.gnu.org)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from )
id 1bAeao-0006rB-Fh
for geb-bug-gnu-emacs@m.gmane.org; Wed, 08 Jun 2016 10:36:26 -0400
Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43801)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from ) id 1bAdzi-0004hu-DG
for bug-gnu-emacs@gnu.org; Wed, 08 Jun 2016 09:58:07 -0400
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from ) id 1bAdze-0004BZ-5t
for bug-gnu-emacs@gnu.org; Wed, 08 Jun 2016 09:58:05 -0400
Original-Received: from debbugs.gnu.org ([208.118.235.43]:48864)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from ) id 1bAdze-0004BB-2S
for bug-gnu-emacs@gnu.org; Wed, 08 Jun 2016 09:58:02 -0400
Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2)
(envelope-from ) id 1bAdzd-0008ML-O4
for bug-gnu-emacs@gnu.org; Wed, 08 Jun 2016 09:58:01 -0400
X-Loop: help-debbugs@gnu.org
Resent-From: Paul Moore
Original-Sender: "Debbugs-submit"
Resent-CC: bug-gnu-emacs@gnu.org
Resent-Date: Wed, 08 Jun 2016 13:58:01 +0000
Resent-Message-ID:
Resent-Sender: help-debbugs@gnu.org
X-GNU-PR-Message: followup 23689
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
Original-Received: via spool by 23689-submit@debbugs.gnu.org id=B23689.146539428132126
(code B ref 23689); Wed, 08 Jun 2016 13:58:01 +0000
Original-Received: (at 23689) by debbugs.gnu.org; 8 Jun 2016 13:58:01 +0000
Original-Received: from localhost ([127.0.0.1]:32968 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from )
id 1bAdzb-0008M5-Nt
for submit@debbugs.gnu.org; Wed, 08 Jun 2016 09:57:59 -0400
Original-Received: from mail-wm0-f44.google.com ([74.125.82.44]:37451)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from ) id 1bAdzZ-0008Ls-A7
for 23689@debbugs.gnu.org; Wed, 08 Jun 2016 09:57:57 -0400
Original-Received: by mail-wm0-f44.google.com with SMTP id k204so18445861wmk.0
for <23689@debbugs.gnu.org>; Wed, 08 Jun 2016 06:57:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=YGnGNfeAhktEXKtlH24SqDHykMDgbcgbQCnl2MLJGxk=;
b=NUC5+hoxfzuZmFUplWq+xMixjORB7A2I5tqLvcx9w5pwYHfo5XDxszOZvZ/HKfKoVb
3sMwKWfWizi9mHNwvnDOozMBRI7Mir6VVFLULaeMwXBjkh9elhUJ2/3ioz9fhO+wg3v6
NtRV5TGGsMMcaZbnBnzaaMG66ozZLMU9zOg3AVPs3XVp5ElULnw2C8yFmrfYR2DX1OhH
WpU5HwupARijd2Mbm4i5SYFY4sT4Alj4gbwPnOS1UQpb8X4UefKt7O5WMjrKAt2XmzKH
Uok6ylv2XqquZDBYXmoHlipEuNHqOLIcpsLYGTIjgaBlCVPvVcK2DCIdbIqUExgR3RX0
7pew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=YGnGNfeAhktEXKtlH24SqDHykMDgbcgbQCnl2MLJGxk=;
b=YpjI2wIq71BtdxbXUmy5E+ND5L4s1/UsoFpvYyuDCtpZJ/xggXXsj3ODW0yqT+m/oT
hWouPwoVVxi/ahHSOZHL4p8C6YHVi1uJ7zfdDuKd1rMdd3BihXDKkTEoAwjvdnYFBKhT
TObMkjgX0/qvcbWVbfqmhccY8iLM69tEI20GlYqXZAwCSuRMVv5Eu6SekaIVk4Jo0Z8E
s8g6oGR2dp0EWG4ik4rEgJS0eCdEUlFdgGvkAxMvO9DQgrIS1QtuGPXKqtNKpxXQwRlq
kxTXoP4/Pdv+CxzKSeQDDyWrEH5gw7WePHz264M5eJ2jkkNzSeikfgaWS6QgYteOirFB
+01g==
X-Gm-Message-State: ALyK8tI1HdxlUOekhUOySWNfXwdtmVBVEsLh3MRT4gMihZ7fQ7MQz7V8WORgmOAW7pyIE5KPYlW+yLgIDE9QkA==
X-Received: by 10.194.148.46 with SMTP id tp14mr4801844wjb.104.1465394270479;
Wed, 08 Jun 2016 06:57:50 -0700 (PDT)
Original-Received: by 10.194.108.136 with HTTP; Wed, 8 Jun 2016 06:57:49 -0700 (PDT)
In-Reply-To:
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: 208.118.235.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:119271
Archived-At:
On 4 June 2016 at 16:17, Paul Moore wrote:
> OK. Thanks for the explanation. I'll report back to the spacemacs
> people. For now, I have a functioning workaround (checking if
> (font-family-list) is non-nil) that will do for the moment. Longer
> term, I can't judge why spacemacs splits the initialisation like this,
> but I'll ask the question.
To follow up on this, it probably would be useful to have some
additional functionality here (or if I've missed something that
already exists, feel free to point me at it!)
What we're doing is attempting to select a font from a list provided
by the user. So we want to call (find-font spec frame) on a list of
font specs in turn. My initial attempt to do this used the
after-make-frame-functions hook to call the font selection code at a
point when this would work (it doesn't work on startup in daemon mode,
as find-font won't work with only the initial daemon frame to work
with). However, when trying to check fonts, I was getting an error
"Window system frame should be used", which (from a brief look at the
source in src/frame.c) seems to imply that the window system is not
(yet?) available on the frame, even though the frame has been created
(that's what the hook means).
As a workaround, I am currently using focus-in-hook, but this is too
late, as if the OS window system doesn't actually focus the new frame,
there is a visible delay before the font gets reset to the correct
value.
Ideally, what I would like to use is either a hook that is fired
shortly after after-make-frame-functions, but when the window system
for the frame is fully initialised, or alternatively a call that I
could use in the after-make-frame-functions hook to say "complete the
initialisation of the window system for this frame right now". Or I
guess maybe it could be considered a bug that when
after-make-frame-functions fires, the frame's display isn't fully
available - but there may be good reasons for that.
I've been trying to put together a reproducible demonstration of the
issue. But it's not easy to do so as everything is happening before
the system is fully initialised (that's basically the point) and my
attempts to track and log what's going on are affecting the results
:-( I'll continue to try to produce an example, but hopefully the
above explanation is sufficient, at least for now.
Paul