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, 15 Jun 2016 16:26:40 +0100

On 15 June 2016 at 15:55, Eli Zaretskii <eliz@gnu.org> wrote:
> Hmm... which could mean it might be easier for you to just modify the
> standard fontset, by adding your fonts as covering the full range of
> the characters each one supports.

No disrespect intended here, but this all sounds pretty complex (and
there's almost no examples I've been able to find on the web of people
doing this in practice). All that's really going on here is that
instead of wanting to customize the default font (something you can do
with one line of code, or via the customize interface) I want to say
"pick whichever one of these 3 fonts actually exists on the system".

There are a number of approaches for this on the web, of various
levels of complexity. But they have issues when used with Windows
daemon mode, which as I reported seems to be due to something peculiar
in how Windows daemon mode works meaning that sometimes find-font
fails if called "at the wrong time" - and the hooks people currently
use seem to trigger that.

Spacemacs at the moment has some code that hooks
server-create-window-system-frame to do initialisation "that needs to
have the display system initialized". That code is fragile, and again
doesn't seem to work on Windows daemon mode. It's used for various
things, only one of which is font selection. In an attempt to get font
selection working, I'm looking at options here - I'm OK with taking
the existing font selection code and moving it to a different hook.
However, finding such a hook is proving hard.

An alternative approach, such as fontsets, to setting the font is
possible, but risks breaking other things in spacemacs that I don't
currently understand (there's code that sets alternate fonts on
fontset-default against certain Unicode characters for a custom
modeline package, for example). So while I'm OK with experimenting
here, and if I understand the resulting process, modifying the
spacemacs code to use it, it would be very easy for me to make things
worse rather than better. Also, in the spacemacs code, choosing from a
list of fonts is covered, albeit via custom code - so if I could find
"the right hook", I wouldn't need to worry about any of this.

My problems with where we've got to with the fontset approach are:
1. I've yet to get it working (pretty basic :-))
2. If I have to define a fontset using the name of a font that's on
the system, how do I obtain such a font name in a cross-platform way?
Can Emacs tell me what would be suitable? Am I allowed to reuse the
font name that was used for the default fontset?
3. I don't want to modify the default fontset, at least in the first
instance, as doing so could break the spacemacs code. Once I have
something working with a custom fontset, then maybe I would be able to
work out how to merge the two bits of code.

At the moment, I'm running the spacemacs font code the first time
after-make-frame-functions runs, and calling select-frame to select
the created frame before I run the spacemacs code. It seems to work,
but I'm unclear why I need to call select-frame, and whether there
might be hidden issues remaining. Also, because I can't set the font
until *after* the frame is created, there's a flicker with the initial
frame opening with the "wrong" font and then resetting.

So - to summarise. There seems to be a lot of complexity here, in
achieving what feels like it ought to be a pretty straightforward
requirement. Your fontset suggestion seemed simple, but on digging
into it it turned out to be more complex that I'd hoped in practice.
If I could get it working it might make sense to rip out the current
spacemacs approach in favour of it, but at the moment it seems like
I'd lose more than I gained. On the other hand, there's clearly some
issues around the idea of a hook that runs "once the display system is
ready" - spacemacs' current hack has problems, and so does any
alternative approach I've tried. But if there genuinely isn't a good
hook we can use (and no likelihood of one being added) then I guess I
have to live with that.

I do appreciate all of the help you've given - and I completely
respect the fact that you don't want to get sucked into what's
essentially a spacemacs issue. But if you have any further suggestions
on how something like this *should* be handled, I'd appreciate them.

Paul





reply via email to

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