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

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

[Paul Moore]

When Emacs starts in daemon mode on Windows, "w32-initialized" is set
to "t" right at the start - before the window system is initialized.
Specifically, before (find-font) will work correctly.

To demonstrate, start Emacs in daemon mode, with a .emacs.d/init.el
containing a statement at the top to display the value of
"w32-initialized". The value "t" is shown.

In GNU Emacs 25.0.93.1 (x86_64-w64-mingw32)
 of 2016-04-23 built on KAEL
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Configured using:
 'configure --prefix=/tmp/emacs --without-imagemagick 'CFLAGS=-O2
 -fomit-frame-pointer -g0''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: ENG
  locale-coding-system: cp1252

Major mode: Emacs-Lisp

Minor modes in effect:
  auto-compile-mode: t
  elisp-slime-nav-mode: t
  goto-address-prog-mode: t
  bug-reference-prog-mode: t
  auto-highlight-symbol-mode: t
  clean-aindent-mode: t
  highlight-numbers-mode: t
  highlight-parentheses-mode: t
  rainbow-delimiters-mode: t
  helm-descbinds-mode: t
  helm-mode: t
  shell-dirtrack-mode: t
  helm-flx-mode: t
  projectile-global-mode: t
  projectile-mode: t
  recentf-mode: t
  hl-todo-mode: t
  winner-mode: t
  window-numbering-mode: t
  volatile-highlights-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  spaceline-info-mode: t
  spaceline-helm-mode: t
  smooth-scrolling-mode: t
  save-place-mode: t
  savehist-mode: t
  popwin-mode: t
  persp-mode: t
  global-page-break-lines-mode: t
  page-break-lines-mode: t
  Info-breadcrumbs-in-mode-line-mode: t
  ido-vertical-mode: t
  flx-ido-mode: t
  global-evil-surround-mode: t
  evil-surround-mode: t
  global-evil-search-highlight-persist: t
  evil-search-highlight-persist: t
  show-smartparens-global-mode: t
  show-smartparens-mode: t
  smartparens-mode: t
  evil-escape-mode: t
  global-anzu-mode: t
  anzu-mode: t
  eval-sexp-fu-flash-mode: t
  spacemacs-leader-override-mode: t
  global-spacemacs-leader-override-mode: t
  global-hl-line-mode: t
  xterm-mouse-mode: t
  global-auto-revert-mode: t
  which-key-mode: t
  override-global-mode: t
  evil-mode: t
  evil-local-mode: t
  diff-auto-refine-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  hs-minor-mode: t

Recent messages:
SPC ESC is undefined
Type y, n, ! or SPC (the space bar):
SPC n ESC is undefined
mode-line-point-position enabled.
mode-line-point-position disabled.
Quit
mode-line-point-position enabled.
Quit
mode-line-point-position disabled.
Type M-x delete-other-windows to remove help window.
mwheel-scroll: End of buffer

Load-path shadows:
c:/Users/UK03306/.emacs.d/elpa/helm-20160530.424/helm-multi-match
hides c:/Users/UK03306/.emacs.d/elpa/helm-core-20160530.52/helm-multi-match

Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec epg
mailabbrev gmm-utils mailheader sendmail mail-utils novice helm-command
helm-elisp helm-eval edebug apropos auto-compile packed elisp-slime-nav
goto-addr bug-reference auto-highlight-symbol clean-aindent-mode
highlight-numbers parent-mode highlight-parentheses hideshow
rainbow-delimiters org-element org-rmail org-mhe org-irc org-info
org-gnus org-docview doc-view jka-compr image-mode org-bibtex bibtex
org-bbdb org-w3m org org-macro org-footnote org-pcomplete org-list
org-faces org-entities noutline outline org-version ob-emacs-lisp ob
ob-tangle ob-ref ob-lob ob-table ob-exp org-src ob-keys ob-comint
ob-core ob-eval org-compat org-macs org-loaddefs find-func cal-menu
calendar cal-loaddefs two-column iso-transl helm-descbinds helm-mode
helm-files image-dired tramp tramp-compat tramp-loaddefs trampver shell
pcomplete format-spec dired-x dired-aux ffap helm-buffers helm-elscreen
helm-tags helm-bookmark helm-adaptive helm-info bookmark helm-locate
helm-grep helm-regexp helm-plugin helm-external helm-net browse-url xml
url url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util mailcap helm-utils helm-help helm-types helm-flx
helm helm-source eieio-compat helm-multi-match helm-lib dired projectile
grep compile ibuf-ext ibuffer recentf tree-widget async hl-todo server
winner window-numbering etags xref project volatile-highlights undo-tree
diff spaceline-config spaceline-segments s ucs-normalize spaceline
powerline powerline-separators color powerline-themes smooth-scrolling
smartparens-config saveplace savehist popwin persp-mode page-break-lines
info+ ido-vertical-mode flx-ido flx ido exec-path-from-shell
evil-surround evil-search-highlight-persist evil-numbers evil-lisp-state
smartparens dash evil-indent-plus evil-exchange evil-escape evil-args
evil-anzu anzu info eval-sexp-fu rx highlight diminish adaptive-wrap
hybrid-mode evil-evilified-state ielm pp comint ansi-color hl-line
xt-mouse autorevert filenotify quelpa url-parse auth-source gnus-util
password-cache url-vars package-build mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mm-util help-fns
mail-prsvr json map lisp-mnt use-package which-key bind-key bind-map
evil evil-integration evil-maps evil-commands evil-jumps
evil-command-window evil-types evil-search evil-ex evil-macros
evil-repeat evil-states evil-core evil-common windmove thingatpt rect
evil-digraphs evil-vars ring vc-git diff-mode time-date wid-edit
spacemacs-dark-theme spacemacs-common finder-inf
core-configuration-layer cl-seq ht cl warnings package epg-config seq
eieio byte-opt bytecomp byte-compile cl-extra help-mode cconv eieio-core
core-spacemacs core-use-package-ext core-micro-state corelv core-toggle
core-keybindings core-fonts-support core-spacemacs-buffer derived
edmacro kmacro core-funcs easy-mmode cl-macs gv core-themes-support
core-display-init core-auto-completion core-release-management
core-emacs-backports core-dotspacemacs core-command-line core-debug
advice profiler easymenu cl-loaddefs cl-lib subr-x pcase mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel dos-w32 ls-lisp disp-table w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote w32notify dbusbind w32
multi-tty make-network-process emacs)

Memory information:
((conses 16 638422 642621)
 (symbols 56 52659 47)
 (miscs 48 502 1408)
 (strings 32 115680 289769)
 (string-bytes 1 3503362)
 (vectors 16 76740)
 (vector-slots 8 1327928 388588)
 (floats 8 2128 6063)
 (intervals 56 1943 2017)
 (buffers 976 21))

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

[Eli Zaretskii]

> From: Paul Moore <p.f.moore@gmail.com>
> Date: Fri, 3 Jun 2016 11:33:00 +0100
> 
> When Emacs starts in daemon mode on Windows, "w32-initialized" is set
> to "t" right at the start - before the window system is initialized.
> Specifically, before (find-font) will work correctly.
> 
> To demonstrate, start Emacs in daemon mode, with a .emacs.d/init.el
> containing a statement at the top to display the value of
> "w32-initialized". The value "t" is shown.

It looks like this is an internal variable whose purpose is to make
sure the w32 GUI initialization code is called only once per session;
it shouldn't be used for any other purpose.  I guess we could make
this more explicit in the doc string, but other than that I see no bug
here.

Thanks.

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

[Paul Moore]

On 4 June 2016 at 11:07, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Paul Moore <p.f.moore@gmail.com>
>> Date: Fri, 3 Jun 2016 11:33:00 +0100
>>
>> When Emacs starts in daemon mode on Windows, "w32-initialized" is set
>> to "t" right at the start - before the window system is initialized.
>> Specifically, before (find-font) will work correctly.
>>
>> To demonstrate, start Emacs in daemon mode, with a .emacs.d/init.el
>> containing a statement at the top to display the value of
>> "w32-initialized". The value "t" is shown.
>
> It looks like this is an internal variable whose purpose is to make
> sure the w32 GUI initialization code is called only once per session;
> it shouldn't be used for any other purpose.  I guess we could make
> this more explicit in the doc string, but other than that I see no bug
> here.

OK. The spacemacs initialisation code uses this variable (along with
ns-initialized and x-initialized) to ensure that certain actions (e.c.
find-font) are only run after the display is initialized. It's only
w32-initialized for which this approach doesn't work. Is there a
better way of testing for this situation that should be used?

Paul

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

[Eli Zaretskii]

> From: Paul Moore <p.f.moore@gmail.com>
> Date: Sat, 4 Jun 2016 11:29:28 +0100
> Cc: 23689@debbugs.gnu.org
> 
> > It looks like this is an internal variable whose purpose is to make
> > sure the w32 GUI initialization code is called only once per session;
> > it shouldn't be used for any other purpose.  I guess we could make
> > this more explicit in the doc string, but other than that I see no bug
> > here.
> 
> OK. The spacemacs initialisation code uses this variable (along with
> ns-initialized and x-initialized) to ensure that certain actions (e.c.
> find-font) are only run after the display is initialized. It's only
> w32-initialized for which this approach doesn't work. Is there a
> better way of testing for this situation that should be used?

Frankly, I'm not sure what is the situation for which you want to
test.  Can you describe the original problem in more detail?

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

[Paul Moore]

On 4 June 2016 at 11:58, Eli Zaretskii <eliz@gnu.org> wrote:
> Frankly, I'm not sure what is the situation for which you want to
> test.  Can you describe the original problem in more detail?

Sure. The issue arises with Spacemacs. I'll give the basic idea (as
well as I understand it, I'm not an expert by any means) but the
actual code is at
https://github.com/syl20bnr/spacemacs/blob/master/core/core-display-init.el#L28

When spacemacs starts up, it wants to set the fonts as configured by
the user. To do so, it checks that the user-selected font exists using
find-font (there's new code in the develop branch that allows the user
to set a list of fonts, and picks the first on the list that actually
exists on the system). But in daemon mode, find-font doesn't return a
useful value until the display system is initialised, so there's a
macro:

(defmacro spacemacs|do-after-display-system-init (&rest body)
  "If the display-system is initialized, run `BODY', otherwise,
add it to a queue of actions to perform after the first graphical frame is
created."
  `(let ((init (cond ((boundp 'ns-initialized) 'ns-initialized)
                     ((boundp 'w32-initialized) 'w32-initialized)
                     ((boundp 'x-initialized) 'x-initialized)
                     (t 't))))           ; fallback to normal loading behavior
     (if (symbol-value init)
         (progn
           ,@body)
       (push (lambda () ,@body) spacemacs--after-display-system-init-list))))

The actions on spacemacs--after-display-system-init-list are executed
when the first GUI frame is displayed, via advice on
server-create-window-system-frame.

This process works fine on non-Windows systems, I guess because
ns-initialized and x-initialized are false during daemon startup. But
on Windows it fails and from my testing this appears to be because
w32-initialized is true at this point (unlike the other two). As a
result, the font selection code gets run immediately - specifically
*before* the point when find-font will give a correct answer.

To demonstrate, create a .emacs.d/init.el containing

(progn
    (message "%S" w32-initialized)
    (message "%S" (find-font (font-spec :name "Courier New")))
    (message "%S" w32-initialized))

Set HOME to the directory containing .emacs.d and run emacs --daemon.
The result is

t
nil
t

Do the same on Unix (I used Ubuntu) using x-initialized (and a font
that exists on the Unix system in place of Courier New) and you get

nil
nil
nil

Do the same using emacs (no --daemon) and look in the *Messages*
buffer, and you see

t
<a font object>
t

in both cases.

Hopefully, that clarifies a little.
Paul

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

[Eli Zaretskii]

> From: Paul Moore <p.f.moore@gmail.com>
> Date: Sat, 4 Jun 2016 13:54:59 +0100
> Cc: 23689@debbugs.gnu.org
> 
> When spacemacs starts up, it wants to set the fonts as configured by
> the user. To do so, it checks that the user-selected font exists using
> find-font (there's new code in the develop branch that allows the user
> to set a list of fonts, and picks the first on the list that actually
> exists on the system). But in daemon mode, find-font doesn't return a
> useful value until the display system is initialised, so there's a
> macro:
> 
> (defmacro spacemacs|do-after-display-system-init (&rest body)
>   "If the display-system is initialized, run `BODY', otherwise,
> add it to a queue of actions to perform after the first graphical frame is
> created."
>   `(let ((init (cond ((boundp 'ns-initialized) 'ns-initialized)
>                      ((boundp 'w32-initialized) 'w32-initialized)
>                      ((boundp 'x-initialized) 'x-initialized)
>                      (t 't))))           ; fallback to normal loading behavior
>      (if (symbol-value init)
>          (progn
>            ,@body)
>        (push (lambda () ,@body) spacemacs--after-display-system-init-list))))
> 
> The actions on spacemacs--after-display-system-init-list are executed
> when the first GUI frame is displayed, via advice on
> server-create-window-system-frame.

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?

> This process works fine on non-Windows systems, I guess because
> ns-initialized and x-initialized are false during daemon startup. But
> on Windows it fails and from my testing this appears to be because
> w32-initialized is true at this point (unlike the other two). As a
> result, the font selection code gets run immediately - specifically
> *before* the point when find-font will give a correct answer.

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).

> To demonstrate, create a .emacs.d/init.el containing
> 
> (progn
>     (message "%S" w32-initialized)
>     (message "%S" (find-font (font-spec :name "Courier New")))
>     (message "%S" w32-initialized))
> 
> Set HOME to the directory containing .emacs.d and run emacs --daemon.
> The result is
> 
> t
> nil
> t
> 
> Do the same on Unix (I used Ubuntu) using x-initialized (and a font
> that exists on the Unix system in place of Courier New) and you get
> 
> nil
> nil
> nil
> 
> Do the same using emacs (no --daemon) and look in the *Messages*
> buffer, and you see
> 
> t
> <a font object>
> t
> 
> in both cases.

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.

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

[Paul Moore]

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

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

[Paul Moore]

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

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

[Eli Zaretskii]

> From: Paul Moore <p.f.moore@gmail.com>
> Date: Wed, 8 Jun 2016 14:57:49 +0100
> Cc: 23689@debbugs.gnu.org
> 
> What we're doing is attempting to select a font from a list provided
> by the user.

What do you mean by "select a font"?  If the font you want to use is
known in advance, then a parameter in default-frame-alist should be
all you need.  If the font is not known in advance, then how do you
"select" it?

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

[Paul Moore]

On 14 June 2016 at 18:10, Eli Zaretskii <eliz@gnu.org> wrote:
>> What we're doing is attempting to select a font from a list provided
>> by the user.
>
> What do you mean by "select a font"?  If the font you want to use is
> known in advance, then a parameter in default-frame-alist should be
> all you need.  If the font is not known in advance, then how do you
> "select" it?

The user supplies a *list* of fonts. The code then goes through those
fonts in turn, checking (via find-font) whether the font exists, and
if it does, then sets it as the frame font and adds it to
default-frame-alist for the future.

The point here is for users who want to move their config between
machines, and don't always have the same fonts installed - so they
would typically put their preferred font first in the list, with
fallback options following.

Paul

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

[Eli Zaretskii]

> From: Paul Moore <p.f.moore@gmail.com>
> Date: Tue, 14 Jun 2016 19:20:27 +0100
> Cc: 23689@debbugs.gnu.org
> 
> The user supplies a *list* of fonts. The code then goes through those
> fonts in turn, checking (via find-font) whether the font exists, and
> if it does, then sets it as the frame font and adds it to
> default-frame-alist for the future.
> 
> The point here is for users who want to move their config between
> machines, and don't always have the same fonts installed - so they
> would typically put their preferred font first in the list, with
> fallback options following.

Sounds like a perfect use case for a fontset: create a fontset from
all those fonts, and then use the name of that fontset as the value of
the 'font' parameter in default-frame-alist.  Emacs will look up the
fonts in the font set one by one until it finds one it can use.

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

[Paul Moore]

On 14 June 2016 at 19:55, Eli Zaretskii <eliz@gnu.org> wrote:
>> The user supplies a *list* of fonts. The code then goes through those
>> fonts in turn, checking (via find-font) whether the font exists, and
>> if it does, then sets it as the frame font and adds it to
>> default-frame-alist for the future.
>>
>> The point here is for users who want to move their config between
>> machines, and don't always have the same fonts installed - so they
>> would typically put their preferred font first in the list, with
>> fallback options following.
>
> Sounds like a perfect use case for a fontset: create a fontset from
> all those fonts, and then use the name of that fontset as the value of
> the 'font' parameter in default-frame-alist.  Emacs will look up the
> fonts in the font set one by one until it finds one it can use.

Hmm. Are they cross-platform? The "Defining fontsets" page in the
Emacs manual talks about X resouces. I'm on Windows, and I don't know
how I'd set up an X resource there.

To give a concrete example, how would I ask Emacs to choose the first
of "Source Code Pro-12", "DevaVu Sans Mono-12", "Consolas-12" or
"Courier New-12" that was present on the machine?

Thanks,
Paul

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

[Eli Zaretskii]

> From: Paul Moore <p.f.moore@gmail.com>
> Date: Tue, 14 Jun 2016 20:55:57 +0100
> Cc: 23689@debbugs.gnu.org
> 
> > Sounds like a perfect use case for a fontset: create a fontset from
> > all those fonts, and then use the name of that fontset as the value of
> > the 'font' parameter in default-frame-alist.  Emacs will look up the
> > fonts in the font set one by one until it finds one it can use.
> 
> Hmm. Are they cross-platform?

Yes.

> The "Defining fontsets" page in the Emacs manual talks about X
> resouces.

X resources are supported on Windows as well, but that's unrelated.
Look in the ELisp manual, not in the user manual.  There are many
examples in fontset.el for you to use.

> I'm on Windows, and I don't know how I'd set up an X resource there.

You don't need X resources to create a fontset.  Use
create-fontset-from-fontset-spec to create a new fontset, and
set-fontset-font to add fonts to the fontset.

> To give a concrete example, how would I ask Emacs to choose the first
> of "Source Code Pro-12", "DevaVu Sans Mono-12", "Consolas-12" or
> "Courier New-12" that was present on the machine?

Make a fontset that includes all these fonts, and then use the fontset
name in the default-frame-alist's 'font' parameter.

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

[Paul Moore]

On 15 June 2016 at 03:33, Eli Zaretskii <eliz@gnu.org> wrote:
>> To give a concrete example, how would I ask Emacs to choose the first
>> of "Source Code Pro-12", "DevaVu Sans Mono-12", "Consolas-12" or
>> "Courier New-12" that was present on the machine?
>
> Make a fontset that includes all these fonts, and then use the fontset
> name in the default-frame-alist's 'font' parameter.

OK. Thanks for the explanation. I didn't know about that :-)
Paul

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

[Paul Moore]

On 15 June 2016 at 08:08, Paul Moore <p.f.moore@gmail.com> wrote:
>> Make a fontset that includes all these fonts, and then use the fontset
>> name in the default-frame-alist's 'font' parameter.
>
> OK. Thanks for the explanation. I didn't know about that :-)

Am I doing something wrong?

(create-fontset-from-fontset-spec
"-*-fixed-medium-r-normal-*-24-*-*-*-*-*-fontset-xxx")
(set-fontset-font "fontset-xxx" nil "Source Code Pro-14")
(set-fontset-font "fontset-xxx" nil "DejaVu Sans Mono-14" nil 'append)
(set-fontset-font "fontset-xxx" nil "Consolas-14" nil 'append)
(set-fontset-font "fontset-xxx" nil "Courier New-14" nil 'append)
(setq default-frame-alist '((font . "fontset-xxx") (vertical-scroll-bars)))

If I then create a new frame, I get the error "Font 'fontset-xxx' is
not defined".

The font parameter for a frame is documented as

     The name of the font for displaying text in the frame.  This is a
     string, either a valid font name for your system or the name of an
     Emacs fontset (*note Fontsets::).  It is equivalent to the ‘font’
     attribute of the ‘default’ face.

Am I not using a correct fontset name here?

Paul

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

[Eli Zaretskii]

> From: Paul Moore <p.f.moore@gmail.com>
> Date: Wed, 15 Jun 2016 12:11:45 +0100
> Cc: 23689@debbugs.gnu.org
> 
> (create-fontset-from-fontset-spec
> "-*-fixed-medium-r-normal-*-24-*-*-*-*-*-fontset-xxx")
> (set-fontset-font "fontset-xxx" nil "Source Code Pro-14")
> (set-fontset-font "fontset-xxx" nil "DejaVu Sans Mono-14" nil 'append)
> (set-fontset-font "fontset-xxx" nil "Consolas-14" nil 'append)
> (set-fontset-font "fontset-xxx" nil "Courier New-14" nil 'append)
> (setq default-frame-alist '((font . "fontset-xxx") (vertical-scroll-bars)))
> 
> If I then create a new frame, I get the error "Font 'fontset-xxx' is
> not defined".

You cannot define a fontset using the name of a font that doesn't exist
on the system.  The doc string of create-fontset-from-fontset-spec
hints on this:

  When a frame uses the fontset as the ‘font’ parameter, the frame’s
  default font name is derived from FONTSET-NAME by substituting
  "iso8859-1" for the tail part "fontset-XXX".

Since there's no fixed-medium font on Windows, Emacs barfs because the
default font of the frame doesn't exist.

You need instead to start with a name of a font that surely exists on
Windows, like "-*-courier new-normal-r-*-*-13-*-*-*-c-*-fontset-xxx".
Then the above will work as expected.

On Unix, you should probably start with fixed-medium, as you did.  If
you want to do that in platform-independent way, you could look up
"fontset-standard" in the list returned by fontset-list, and chop off
the "fontset-standard" part.

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.

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

[Paul Moore]

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

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

[Eli Zaretskii]

> From: Paul Moore <p.f.moore@gmail.com>
> Date: Wed, 15 Jun 2016 16:26:40 +0100
> Cc: 23689@debbugs.gnu.org
> 
> 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.

> Am I allowed to reuse the font name that was used for the default
> fontset?

Sure, why not?

> 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.

> 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.

> 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.

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

[Paul Moore]

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

[Stefan Kangas]

Paul Moore <p.f.moore@gmail.com> writes:

>>> 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.

Having read the discussion, it seems to me like there is no bug here,
so I'm closing this now.  If that's incorrect, please reopen the bug
report.

Best regards,
Stefan Kangas