[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 17:58:43 +0100 |
On 15 June 2016 at 16:47, Eli Zaretskii <eliz@gnu.org> wrote:
>> 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?
>
> I suggested a way of doing that in my previous message.
Sorry, I missed that (I focused straight on "you could modify the
default fontset"). My mistake, sorry.
>> Am I allowed to reuse the font name that was used for the default
>> fontset?
>
> Sure, why not?
Yes, that follows from the above. As to "why not" I was thinking of it
as being the name of the fontset, and so possibly having to be unique.
I understand now.
>> 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.
>
> It's not straightforward, it's pretty advanced stuff. Most users
> don't mess with fontsets, and if they want to customize fonts, they
> know their favorite fonts in advance.
In terms of what I'm learning, it's definitely advanced! (And your
help is appreciated). I always though of the *idea* of a fallback font
as pretty basic, though (but maybe that's simply because I came from
Vim, where it's built in).
>> 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.
>
> The problem is that "hook that runs once the display system is ready"
> is not well defined. "The display system" includes several
> components, and the order and timing of their setup do not necessarily
> fit your specific needs.
OK, I get that. As I say, it's just a reality that I'll have to live with.
>> 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.
>
> Sorry, I don't know enough about spacemacs to tell anything else.
No problem. And now that you pointed out the part of your previous
message that I missed, I have enough to go on.
Many thanks for your time and help.
Paul
- bug#23689: Daemon-mode on Windows - "w32-initialized" is set too early, (continued)
- bug#23689: Daemon-mode on Windows - "w32-initialized" is set too early, Eli Zaretskii, 2016/06/14
- bug#23689: Daemon-mode on Windows - "w32-initialized" is set too early, Paul Moore, 2016/06/14
- bug#23689: Daemon-mode on Windows - "w32-initialized" is set too early, Eli Zaretskii, 2016/06/14
- bug#23689: Daemon-mode on Windows - "w32-initialized" is set too early, Paul Moore, 2016/06/14
- bug#23689: Daemon-mode on Windows - "w32-initialized" is set too early, Eli Zaretskii, 2016/06/14
- bug#23689: Daemon-mode on Windows - "w32-initialized" is set too early, Paul Moore, 2016/06/15
- bug#23689: Daemon-mode on Windows - "w32-initialized" is set too early, Paul Moore, 2016/06/15
- bug#23689: Daemon-mode on Windows - "w32-initialized" is set too early, Eli Zaretskii, 2016/06/15
- bug#23689: Daemon-mode on Windows - "w32-initialized" is set too early, Paul Moore, 2016/06/15
- bug#23689: Daemon-mode on Windows - "w32-initialized" is set too early, Eli Zaretskii, 2016/06/15
- bug#23689: Daemon-mode on Windows - "w32-initialized" is set too early,
Paul Moore <=