properly setting up ~/.emacs.d for daemon usage

properly setting up ~/.emacs.d for daemon usage

[Filipe Silva]

Dear users and developers of the mighty emacs editor,

I'm deeply in love with the --deamon feature, but I'm encountering a
scenario that I'm having a hard time to solve.

When I start emacs with emacs --daemon, emacs does not know if I wan't to
run emacs as a GUI or inside a terminal,
therefore all the checks inside my ~/.emacs.d init code which use
(display-graphic-p) will not work,
e.g. emacs will think that I have no gui because display-graphic-p will
return nil.

likewise, using (daemon-p) while my `~/.emacs.d/` config is loading up will
not work
because emacs has not loaded yet: the daemon boostrap procedure is not
complete so (daemon-p) dutifully returns nil.

The end result is: if I later try to connect to said daemon using
emacsclient pulling up a gui-frame, all the colors are off because emacs
thought that I had no gui.

Seems that the solution for that would be to put a hook somewhere that
would activate when an emacs frame is created. In this hook, I'd have to
put all my initialization code that is gui-dependent.

Make sense? How would an emacs user properly setup his ~/.emacs.d/ so that
it plays well with the daemon feature?

thanks in advance,

Ninrod

Re: properly setting up ~/.emacs.d for daemon usage

[Óscar Fuentes]

Filipe Silva <filipe.silva@gmail.com> writes:

[snip]

> Make sense? How would an emacs user properly setup his ~/.emacs.d/ so that
> it plays well with the daemon feature?

What's your specific problem? Themes should work fine regardless of you
using --daemon. Just call load-theme as usual.

If you want different settings for graphical frames than from text
frames, use after-make-frame-functions. There, put a function that
checks if the current frame is graphical/textual and apply the
corresponding settings.

FWIW, I use --daemon all the time and so far had no need for such
function. If the above still does not resolve your problem, please show
one of those snippets which depend on display-graphic-p.

Re: properly setting up ~/.emacs.d for daemon usage

[Stefan Monnier]

> Seems that the solution for that would be to put a hook somewhere that
> would activate when an emacs frame is created. In this hook, I'd have to
> put all my initialization code that is gui-dependent.

To some extent.  A lot of the configuration can be done globally, but
some probably need to go to places like after-make-frame-functions.

The important thing to consider is that you can have both gui and tty
frames at the same time.  And you can also have gui frames on several
displays at the same time.


        Stefan

Re: properly setting up ~/.emacs.d for daemon usage

[Filipe Silva]

​Óscar, sure. Here are some specifics:

1) The gui theme I use, zerodark (By Nicolas Petton, who is redesign
elpa.gnu.org), queries display-graphic-p everytime it goes about defining a
palete element:

https://github.com/NicolasPetton/zerodark-theme/blob/master/zerodark-theme.el#L158-L162

So If I load my emacs with emacs --daemon, in the configuration section
that calls (load-theme), (display-graphic-p) will not work because emacs
does not know if I'll go tty or gui. That type of code is prevalent in
various other popular themes. Here's spacemacs using display-graphic-p:
https://github.com/nashamri/spacemacs-theme/blob/master/spacemacs-common.el#L69-L72

2) I would be glad if I could define two separate themes for gui and for
tty. I'd even be willing to have two separate daemons: one for gui, and one
for tty. I've already did that with success using (setq server-use-tcp t).
and then:

emacs --daemon=gui
emacs --daemon=tty
emacsclient --server-file=
​gui
 -c -n
emacsclient --server-file=
​tty
 -c -n

​But this does not solve issue 1).

3) there are some packages, like
https://github.com/7696122/evil-terminal-cursor-changer,
that only make sense in a tty frame. Since emacs --daemon does not know
what I'm going to use, (unless I use approach 2. which does not solve issue
1.)  I can't really setup a condition that loads or not the package
accordingly.


​I think that sums it up,

Thoughts?

Thanks in advance

Ninrod.​


On Mon, 12 Dec 2016 at 00:10 Óscar Fuentes <ofv@wanadoo.es> wrote:

> Filipe Silva <filipe.silva@gmail.com> writes:
>
>
>
> [snip]
>
>
>
> > Make sense? How would an emacs user properly setup his ~/.emacs.d/ so
> that
>
> > it plays well with the daemon feature?
>
>
>
> What's your specific problem? Themes should work fine regardless of you
>
> using --daemon. Just call load-theme as usual.
>
>
>
> If you want different settings for graphical frames than from text
>
> frames, use after-make-frame-functions. There, put a function that
>
> checks if the current frame is graphical/textual and apply the
>
> corresponding settings.
>
>
>
> FWIW, I use --daemon all the time and so far had no need for such
>
> function. If the above still does not resolve your problem, please show
>
> one of those snippets which depend on display-graphic-p.
>
>
>
>
>
>

Re: properly setting up ~/.emacs.d for daemon usage

[Óscar Fuentes]

Filipe Silva <filipe.silva@gmail.com> writes:

> ​Óscar, sure. Here are some specifics:
>
> 1) The gui theme I use, zerodark (By Nicolas Petton, who is redesign
> elpa.gnu.org), queries display-graphic-p everytime it goes about defining a
> palete element:
>
> https://github.com/NicolasPetton/zerodark-theme/blob/master/zerodark-theme.el#L158-L162

That package assumes that a session will be either graphical or textual.
Apart from --daemon, you can activate server mode on any Emacs session,
thus making possible to create frames of either type.

From my POV packages like this one are broken. Emacs allows to define
faces providing conditional values: this for ttys and that for X, etc. I
don't know why those themes go the (display-graphic-p) route.

You could advise display-graphic-p to return a value depending on how do
you intend to use that daemon. Try looking into command-line-args for
"--daemon=XXX" or, if that argument was already consumed, put some other
mark on the command line such as --eval="(quote graphical)".

Re: properly setting up ~/.emacs.d for daemon usage

[Yuri Khan]

On Mon, Dec 12, 2016 at 9:10 PM, Filipe Silva <filipe.silva@gmail.com> wrote:

> 1) The gui theme I use, zerodark (By Nicolas Petton, who is redesign
> elpa.gnu.org), queries display-graphic-p everytime it goes about defining a
> palete element:
>
> https://github.com/NicolasPetton/zerodark-theme/blob/master/zerodark-theme.el#L158-L162

    (defun true-color-p ()
      "Return non-nil on displays that support 256 colors."
      (or
        (display-graphic-p)
        (= (tty-display-color-cells) 16777216)))

    (let ((class '((class color) (min-colors 89)))
          (default (if (true-color-p) "#abb2bf" "#afafaf"))
          […]
          (background (if (true-color-p) "#282c34" "#333333"))
          […])
      (custom-theme-set-faces
        'zerodark
        `(default ((,class (:background ,background :foreground ,default))))
        […])

There should be no reason to check capabilities of the current display
at theme initialization time. Instead, the theme should state its
preferred attributes for each supported type of display and let the
face system deal with it.

What the above code does is, taking into account only the frame which
is selected at the time of initialization:

* if its display is graphical or its terminal supports exactly
16777216 colors, then it sets the default face for 89-or-more-colored
displays to #abb2bf on #282c34;
* alternatively, if the display of that frame is non-graphical and its
terminal supports a number of color other than 16777216, then it sets
the default face for 89-or-more-colored displays to #afafaf on
#333333.

What it seems it *intended* to be doing is, unconditionally:

* set the default face to #abb2bf on #282c34 for any color display
supporting at least 16777216 colors (and it should not matter if it’s
graphical as long as it supports 24-bit color); and
* set the default face to #afafaf on #333333 for all other displays; and
* hope nothing breaks too badly on displays that are too primitive to
display even that (which notably includes the Linux tty).

    (let ((truecolor '((class color) (min-colors 16777216))))
      (custom-theme-set-faces
        'zerodark
        `(default ((default (:background "#333333" :foreground "#afafaf"))
                   (,truecolor (:background "#282c34" :foreground "#abb2bf"))))
        […])

> 3) there are some packages, like
> https://github.com/7696122/evil-terminal-cursor-changer,
> that only make sense in a tty frame. Since emacs --daemon does not know
> what I'm going to use, (unless I use approach 2. which does not solve issue
> 1.)  I can't really setup a condition that loads or not the package
> accordingly.

So load them always, and report bugs against them if they break in
presence of frames of type they don’t expect.

Re: properly setting up ~/.emacs.d for daemon usage

[Filipe Silva]

On Mon, Dec 12, 2016 at 1:34 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:

>
>
>
>
​Hum. Óscar and Yuri, would't place the load-theme call inside the
create-frame hook solve the problem?​

Re: properly setting up ~/.emacs.d for daemon usage

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Mon, 12 Dec 2016 23:46:47 +0700
> Cc: Óscar Fuentes <ofv@wanadoo.es>,
> 	"help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
> 
> On Mon, Dec 12, 2016 at 9:10 PM, Filipe Silva <filipe.silva@gmail.com> wrote:
> 
>     (defun true-color-p ()
>       "Return non-nil on displays that support 256 colors."
>       (or
>         (display-graphic-p)
>         (= (tty-display-color-cells) 16777216)))

Why not just look at the value returned by display-color-cells?  It
supports the various terminal types internally.

Re: properly setting up ~/.emacs.d for daemon usage

[Óscar Fuentes]

Filipe Silva <filipe.silva@gmail.com> writes:

> ​Hum. Óscar and Yuri, would't place the load-theme call inside the
> create-frame hook solve the problem?​

At that point display-graphic-p should work fine, so yes (*)

(defun my-after-make-frame-function (_frame)
  (load-theme 'my-awesome-theme t))

(add-hook 'after-make-frame-functions 'my-after-make-frame-function)


* Depending on the exact meaning of "the problem" :-) People with
  different use cases (mine included) might find that solution
  unsatisfactory.

Re: properly setting up ~/.emacs.d for daemon usage

[Yuri Khan]

On Tue, Dec 13, 2016 at 1:47 AM, Filipe Silva <filipe.silva@gmail.com> wrote:

> Hum. Óscar and Yuri, would't place the load-theme call inside the
> create-frame hook solve the problem?

Work around the problem, yes. Solve the problem, no.

Re: properly setting up ~/.emacs.d for daemon usage

[Filipe Silva]

Interestingly enough, (display-graphic-p) still does not work even if
called from inside a function added to the after-make-frame-functions list.


I don't know what I can do here. So even this is not a work around.

On Tue, Dec 13, 2016 at 9:07 AM, Yuri Khan <yuri.v.khan@gmail.com> wrote:

> On Tue, Dec 13, 2016 at 1:47 AM, Filipe Silva <filipe.silva@gmail.com>
> wrote:
>
> > Hum. Óscar and Yuri, would't place the load-theme call inside the
> > create-frame hook solve the problem?
>
> Work around the problem, yes. Solve the problem, no.
>

Re: properly setting up ~/.emacs.d for daemon usage

[Óscar Fuentes]

Filipe Silva <filipe.silva@gmail.com> writes:

> Interestingly enough, (display-graphic-p) still does not work even if
> called from inside a function added to the after-make-frame-functions
> list.

Maybe it "fails" because there is no selected frame yet. What's the
value returned by `selected-frame' inside that function?

It would be useful to show the actual code here.

> I don't know what I can do here. So even this is not a work around.

Try activating the theme *after* a frame was created and selected. That
means, execute (select-frame (make-frame)) at the top of your
.emacs when you intend to use that session on a graphical display. This
is not a general solution, but may be good enough for you.

Re: properly setting up ~/.emacs.d for daemon usage

[Filipe Silva]

Is there a way to advice the daemon loading procedure that this daemon will
be used solely for gui frames so for all intents and purposes, treat
(display-graphic-p) and related functions as if a gui frame is available?

On Tue, Dec 13, 2016 at 7:31 PM, Filipe Silva <filipe.silva@gmail.com>
wrote:

> Interestingly enough, (display-graphic-p) still does not work even if
> called from inside a function added to the after-make-frame-functions list.
>
>
> I don't know what I can do here. So even this is not a work around.
>
> On Tue, Dec 13, 2016 at 9:07 AM, Yuri Khan <yuri.v.khan@gmail.com> wrote:
>
>> On Tue, Dec 13, 2016 at 1:47 AM, Filipe Silva <filipe.silva@gmail.com>
>> wrote:
>>
>> > Hum. Óscar and Yuri, would't place the load-theme call inside the
>> > create-frame hook solve the problem?
>>
>> Work around the problem, yes. Solve the problem, no.
>>
>
>

Re: properly setting up ~/.emacs.d for daemon usage

[Óscar Fuentes]

Filipe Silva <filipe.silva@gmail.com> writes:

> Is there a way to advice the daemon loading procedure that this daemon will
> be used solely for gui frames so for all intents and purposes, treat
> (display-graphic-p) and related functions as if a gui frame is available?

I don't think so, but you can advise display-graphic-p to return
whatever you decide, as I suggested on a previous reply.

Re: properly setting up ~/.emacs.d for daemon usage

[Kaushal Modi]

Hi Filipe,

I have stumbled across this in the past. Here's the solution that works for
me to get a config that works when daemonp is nil/non-nil and
display-graphic-p is nil/non-nil:

https://github.com/kaushalmodi/.emacs.d/blob/master/init.el

Search for focus-in-hook in there and look at that code and the comment
explanation above that.

I am traveling, else I would have typed clean directly reusable code
snippets over here.

Another way to deal with setup that works regardless of the session being
daemonp is to load the setup after some delay. I do that for loading
desktop sessions:


;; Delay desktop setup by a second.
;; - This speeds up emacs init, and
;; - Also (n)linum and other packages would already be loaded which the
files
;; being loaded from the saved desktop might need.
(use-package setup-desktop :defer 1)

So there are no daemonp startup issues like "linum font face not defined",
etc.

About loading themes, I do that in window-setup-hook, because that always
runs whether or not daemonp is non-nil.  Search for window-setup-hook in
https://github.com/kaushalmodi/.emacs.d/blob/master/setup-files/setup-visual.el

Hope this helps.
-- 

Kaushal Modi

Re: properly setting up ~/.emacs.d for daemon usage

[Filipe Silva]

Kaushal, I found it:

https://github.com/kaushalmodi/.emacs.d/blob/master/init.el#L345-L358

This looks very interesting. I'll try that. Thanks.

Ninrod


On Tue, Dec 13, 2016 at 9:49 PM, Kaushal Modi <kaushal.modi@gmail.com>
wrote:

> Hi Filipe,
>
> I have stumbled across this in the past. Here's the solution that works
> for me to get a config that works when daemonp is nil/non-nil and
> display-graphic-p is nil/non-nil:
>
> https://github.com/kaushalmodi/.emacs.d/blob/master/init.el
>
> Search for focus-in-hook in there and look at that code and the comment
> explanation above that.
>
> I am traveling, else I would have typed clean directly reusable code
> snippets over here.
>
> Another way to deal with setup that works regardless of the session being
> daemonp is to load the setup after some delay. I do that for loading
> desktop sessions:
>
>
> ;; Delay desktop setup by a second.
> ;; - This speeds up emacs init, and
> ;; - Also (n)linum and other packages would already be loaded which the
> files
> ;; being loaded from the saved desktop might need.
> (use-package setup-desktop :defer 1)
>
> So there are no daemonp startup issues like "linum font face not defined",
> etc.
>
> About loading themes, I do that in window-setup-hook, because that always
> runs whether or not daemonp is non-nil.  Search for window-setup-hook in
> https://github.com/kaushalmodi/.emacs.d/blob/master/setup-files/setup-
> visual.el
>
> Hope this helps.
> --
>
> Kaushal Modi
>