Font in daemon mode

[wsddn]

When started in daemon mode the font in Emacs reverts to the default one because the font is not set for each frame.

There are two options:

• Change .Xresources to include Emacs.font: Source Code Pro-10 (which I'd have to do).
• Set the frame font in the emacs config, it avoids duplication. (which would be done in spacemacs)

Should the second option be implemented in spacemacs?

See: https://stackoverflow.com/questions/3984730/emacs-gui-with-emacs-daemon-not-loading-fonts-correctly

[syl20bnr]

Very nice find! I'll try this shortly.

[syl20bnr]

@tang0th well it is already implemented: https://github.com/syl20bnr/spacemacs/blob/master/core/spacemacs-mode.el#L160

Use spacemacs/set-font to set your font instead. I will add a dotspacemacs variable to make it ore convenient.

[syl20bnr]

regression since the refactoring of dotspacemacs-default-font

[syl20bnr]

other regression linked to the refactoring #535

[hijarian]

@syl20bnr I confirm this bug. On the following screenshot to the left is the frame opened by emacsclient and to the right - by emacs. I have emacs --daemon running.

Also, after I closed the right-hand-side Emacs window, which was opened by calling emacs from command line, emacs process in that command line wasn't stopped. This must be the separate issue, though.

[antoszka]

I can confirm that the issue can be partly worked around by adding the same default font to .Xdefaults, but the curvy bits of the status line are still broken: https://antoszka.pl/perm/a06a7a6af3de69273034b6eaba9b08685f0cdbdf.png ← I'm running a totally default checkout (done an hour ago), emacs 24.5.1, Lucid toolkit.

[travisbhartwell]

I have started a fix for this and the status line issues. I have pushed a work in progress branch that seems to correctly work for the fonts. Now I need to go through the set up code for powerline, etc and find what would behave differently in text vs graphical modes.

If anyone has a cleaner way of doing this, let me know:

My branch:
https://github.com/travisbhartwell/spacemacs/tree/fix/daemon-mode-and-graphical-frames

The commit with the font change:
travisbhartwell@296cc3f

[travisbhartwell]

Also, I notice display-graphic-p used in spacemacs/packages.el and perhaps that is more correct to use than window-system. Not sure what the difference between the two is.

[travisbhartwell]

Further testing notices that opening successive frames doesn't work correctly. This was just a test. I think this is the right track though.

[robbyoconnor]

@travisbhartwell -- why not write some unit tests (is that even possible?)

[travisbhartwell]

So I did some further hacking this morning and even if I only run this on the first graphical frame, subsequent frames do not get set properly. It's like it's losing the information.

A friend shares this for how they use fonts and daemon mode: https://gist.github.com/RichardBarrell/756116c9ac41c1c1454b

From this, I wonder if the appropriate thing to do instead of calling set-default-font in core-fonts-support.el is to set 'font in default-frame-alist and that would carry over. Thoughts on this @syl20bnr ? I'm willing to continue to work on this.

[syl20bnr]

@travisbhartwell I'm OK with any solution that improves the current situation.

[travisbhartwell]

I made some more progress. Someone #emacs on Freenode pointed out the existence of window-system-initialization-alist, which points to functions appropriate to the particular window system. For example x-initialize-window-system on X, ns-initialize-window-system on Cocoa builds on OS X, etc.

Since there are no hooks provided for these functions, we can use advising. I just tried a test. In init.el, I added the following lines:

(if (not x-initialized)
    (advice-add 'x-initialize-window-system :after
                (lambda (x)
                  (message "*************************Initializing Spacemacs!")))
  (message "*************************Initializing Spacemacs!"))

Since in regular startup X is already initialized by the time init.el is evaluated, simply advising the function is not enough.

I suggest we make a macro that essentially does this, perhaps spacemacs//do-after-display-system-initialized (okay, bad name, need to come up with something better), that will do the BODY if the display system is already initialized. If not, it will queue the body to do once it is. The macro would handle the platform specific variables and functions.

Perhaps we could just advice the initialization function once and then just have the macro add a lambda function containing the BODY to a list of functions that the advised function then calls in order.

Then we need to go through every part of the Spacemacs initialization (font selection, powerline setup, theme setup, etc) and wrap this macro around it.

What do you think @syl20bnr?

I've been discussing this with @cmccloud on IRC about this, particularly OS X portions.

[cmccloud]

@travisbhartwell and I put this together and it seems to work - he ran some tests running emacs as a daemon and variable values deferred by the macro were nil until the initial launch of x-windows, after which they were set.

(defvar spacemacs//after-display-system-init-list '())

(advice-add (cond ((eq system-type 'darwin) 'ns-initialize-window-system)
                  ((eq system-type 'windows-nt) 'w32-initialize-window-system)
                  ((eq system-type 'gnu/linux) 'x-initialize-window-system))
            :after
            (lambda (&rest args)
              (mapcar (lambda (fn) (funcall fn))
                     (reverse spacemacs//after-display-system-init-list))))

(defmacro spacemacs//do-after-display-system-init (&rest body)
  `(let ((init (cond ((eq system-type 'darwin) 'ns-initialized)
                     ((eq system-type 'windows-nt) 'w32-initialized)
                     ((eq system-type 'gnu/linux) 'x-initialized)
                     (t 't))))           ; fallback to normal loading behavior
     (if (symbol-value init)
         ,@body
       (push (lambda () ,@body) spacemacs//after-display-system-init-list))))

Let us know if you have any thoughts.

[syl20bnr]

I like it, good job guys 👍
I suggest to create a new core file that can be required in core-spacemacs.el. The file could be named core-display-init.el.

I'm not sure about the state of Spacemacs 24.3 compatibility, I know that magit requires 24.4 now but we cannot use advice-add if we want core to remain 24.3 compliant.

I really like the new advice API, I wonder if I should drop the support of 24.3.

[travisbhartwell]

Oh, I didn't think about that. If we want 24.3 support, I can change this to use defadvice. Let me know what to do.

[brorbw]

This is still an inssue on Mac OS, Emacs 26.1 on
commit 9865e77
Was there a fix for this issue?