From: Paul Moore <p.f.moore@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 23689@debbugs.gnu.org
Subject: bug#23689: Daemon-mode on Windows - "w32-initialized" is set too early
Date: Sat, 4 Jun 2016 16:17:45 +0100 [thread overview]
Message-ID: <CACac1F9pGmaNhHMDUC16HBhUto=KFnVTdS7RkXk_A-bnY4YhYQ@mail.gmail.com> (raw)
In-Reply-To: <83porxuhfo.fsf@gnu.org>
On 4 June 2016 at 16:01, Eli Zaretskii <eliz@gnu.org> wrote:
> If spacemacs has a way to run code when the first GUI frame is
> created, why cannot it do everything at that time? Why does it have
> to test the above conditions on top of that?
[...]
> I think spacemacs should not rely on the other FOO-initialized
> variables, either, even if they appear to work for now. They are not
> intended to serve as evidence or trigger for any application-level
> logic. Instead, it should do this in a hook function (make-frame
> provides at least 2).
[...]
> That "window-system initialized" automatically implies that find-font
> will work is IMO an invalid assumption. Exactly what parts of the
> initialization are run in FOO-initialize functions is implementation
> detail. I recommend to stay away of such assumption and instead use
> the hooks we provide during startup. Even if you come to the
> conclusion that no existing hook serves spacemacs well enough, and we
> then (say) add yet another hook, the result will be cleaner than
> relying on semi-documented variables and undocumented assumptions.
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.
Paul
next prev parent reply other threads:[~2016-06-04 15:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-03 10:33 bug#23689: Daemon-mode on Windows - "w32-initialized" is set too early Paul Moore
2016-06-04 10:07 ` Eli Zaretskii
2016-06-04 10:29 ` Paul Moore
2016-06-04 10:58 ` Eli Zaretskii
2016-06-04 12:54 ` Paul Moore
2016-06-04 15:01 ` Eli Zaretskii
2016-06-04 15:17 ` Paul Moore [this message]
2016-06-08 13:57 ` Paul Moore
2016-06-14 17:10 ` Eli Zaretskii
2016-06-14 18:20 ` Paul Moore
2016-06-14 18:55 ` Eli Zaretskii
2016-06-14 19:55 ` Paul Moore
2016-06-15 2:33 ` Eli Zaretskii
2016-06-15 7:08 ` Paul Moore
2016-06-15 11:11 ` Paul Moore
2016-06-15 14:55 ` Eli Zaretskii
2016-06-15 15:26 ` Paul Moore
2016-06-15 15:47 ` Eli Zaretskii
2016-06-15 16:58 ` Paul Moore
2019-11-02 1:07 ` Stefan Kangas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACac1F9pGmaNhHMDUC16HBhUto=KFnVTdS7RkXk_A-bnY4YhYQ@mail.gmail.com' \
--to=p.f.moore@gmail.com \
--cc=23689@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).