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