bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#23689: Daemon-mode on Windows - "w32-initialized" is set too early


From: Paul Moore
Subject: bug#23689: Daemon-mode on Windows - "w32-initialized" is set too early
Date: Wed, 8 Jun 2016 14:57:49 +0100

On 4 June 2016 at 16:17, Paul Moore <p.f.moore@gmail.com> 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





reply via email to

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