Help using the right hook for loading theme on emacs daemon GUI

Help using the right hook for loading theme on emacs daemon GUI

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]

Hello,

I noticed that the windows hooks have been revamped recently in
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=0aece3e1181e66f2a1a067ae876e55bdaa45edd5
.

But that breaks the theme loading in my config, and I'd like to know the
correct way to do the same after this change.

At present, I have this in my config:

=====

;; Load the theme ONLY after the frame has finished loading (needed
especially
;; when running emacs in daemon mode)
;;
https://github.com/Malabarba/smart-mode-line/issues/84#issuecomment-46429893
;; ;; `after-make-frame-functions' hook is not run in no-window mode
;; (add-hook 'after-make-frame-functions (lambda (&rest frame)
;;                                         (funcall default-theme-fn)))
(add-hook 'window-setup-hook (lambda () (funcall default-theme-fn)))
=====

The `default-theme-fn' is just a wrapper function that `load-theme's my
theme.

Earlier, on launching emacsclient, that function would get called after the
frame loading finished.

But with the recent change, that function probably gets called before the
frame loading has finished, and so the function is ineffective.

If I manually load my theme after the frame launches, I get my old theme
back.

So, what should I replace `window-setup-hook' with that runs in both -nw
mode and GUI mode emacsclient?

Thanks!


--
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 2077 bytes --]

Re: Help using the right hook for loading theme on emacs daemon GUI

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 569 bytes --]

On Thu, Jan 17, 2019 at 10:44 AM Kaushal Modi <kaushal.modi@gmail.com>
wrote:

> Hello,
>
> I noticed that the windows hooks have been revamped recently in
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=0aece3e1181e66f2a1a067ae876e55bdaa45edd5
> .
>
> But that breaks the theme loading in my config, and I'd like to know the
> correct way to do the same after this change.
>


Some more info:

Now during emacs init, I get this new warning too:

> face-attribute: Invalid face: tooltip

So probably window-setup-hook is getting run before frame init is over?

[-- Attachment #2: Type: text/html, Size: 1225 bytes --]

Re: Help using the right hook for loading theme on emacs daemon GUI

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Thu, 17 Jan 2019 10:49:20 -0500
> 
> Now during emacs init, I get this new warning too:
> 
> > face-attribute: Invalid face: tooltip
> 
> So probably window-setup-hook is getting run before frame init is over?

No, I think this is a bug caused by the pdumper.

Re: Help using the right hook for loading theme on emacs daemon GUI

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]

On Thu, Jan 17, 2019 at 10:55 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Kaushal Modi <kaushal.modi@gmail.com>
> > Date: Thu, 17 Jan 2019 10:49:20 -0500
> >
> > Now during emacs init, I get this new warning too:
> >
> > > face-attribute: Invalid face: tooltip
> >
> > So probably window-setup-hook is getting run before frame init is over?
>
> No, I think this is a bug caused by the pdumper.
>

Thanks.

Another data point: This issue occurs with emacsclient GUI, but not with
emacs GUI.

[-- Attachment #2: Type: text/html, Size: 941 bytes --]

Re: Help using the right hook for loading theme on emacs daemon GUI

[Daniel Colascione]

> On Thu, Jan 17, 2019 at 10:55 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > From: Kaushal Modi <kaushal.modi@gmail.com>
>> > Date: Thu, 17 Jan 2019 10:49:20 -0500
>> >
>> > Now during emacs init, I get this new warning too:
>> >
>> > > face-attribute: Invalid face: tooltip
>> >
>> > So probably window-setup-hook is getting run before frame init is
>> over?
>>
>> No, I think this is a bug caused by the pdumper.
>>
>
> Thanks.
>
> Another data point: This issue occurs with emacsclient GUI, but not with
> emacs GUI.


Yep. I'll look at it. It's worth testing this sort of weirdness with
--with-dumping=unexec too.

Re: Help using the right hook for loading theme on emacs daemon GUI

[martin rudalics]

 > I noticed that the windows hooks have been revamped recently in
 > https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=0aece3e1181e66f2a1a067ae876e55bdaa45edd5
 > .
 >
 > But that breaks the theme loading in my config, and I'd like to know the
 > correct way to do the same after this change.
 >
 > At present, I have this in my config:
 >
 > =====
 >
 > ;; Load the theme ONLY after the frame has finished loading (needed
 > especially
 > ;; when running emacs in daemon mode)
 > ;;
 > https://github.com/Malabarba/smart-mode-line/issues/84#issuecomment-46429893
 > ;; ;; `after-make-frame-functions' hook is not run in no-window mode
 > ;; (add-hook 'after-make-frame-functions (lambda (&rest frame)
 > ;;                                         (funcall default-theme-fn)))
 > (add-hook 'window-setup-hook (lambda () (funcall default-theme-fn)))
 > =====
 >
 > The `default-theme-fn' is just a wrapper function that `load-theme's my
 > theme.
 >
 > Earlier, on launching emacsclient, that function would get called after the
 > frame loading finished.
 >
 > But with the recent change, that function probably gets called before the
 > frame loading has finished, and so the function is ineffective.
 >
 > If I manually load my theme after the frame launches, I get my old theme
 > back.
 >
 > So, what should I replace `window-setup-hook' with that runs in both -nw
 > mode and GUI mode emacsclient?

Window change functions are neither related to 'window-setup-hook' nor
to 'after-make-frame-functions'.  Historically, window change
functions can be run for a frame only "after that frame has been made"
and nothing has changed in this regard (hopefully).

I suppose that what you see is Bug#34114.

martin

Re: Help using the right hook for loading theme on emacs daemon GUI

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

On Thu, Jan 17, 2019 at 1:33 PM martin rudalics <rudalics@gmx.at> wrote:

>
> Window change functions are neither related to 'window-setup-hook' nor
> to 'after-make-frame-functions'.  Historically, window change
> functions can be run for a frame only "after that frame has been made"
> and nothing has changed in this regard (hopefully).
>
> I suppose that what you see is Bug#34114.
>

Hi Martin,

Sorry for the false ping. Indeed, that bug is the exact same issue I am
seeing.

Thanks.

[-- Attachment #2: Type: text/html, Size: 885 bytes --]

Re: Help using the right hook for loading theme on emacs daemon GUI

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Thu, 17 Jan 2019 10:44:05 -0500
> 
> At present, I have this in my config:
> 
> =====
> 
> ;; Load the theme ONLY after the frame has finished loading (needed especially
> ;; when running emacs in daemon mode)
> ;; https://github.com/Malabarba/smart-mode-line/issues/84#issuecomment-46429893
> ;; ;; `after-make-frame-functions' hook is not run in no-window mode
> ;; (add-hook 'after-make-frame-functions (lambda (&rest frame)
> ;;                                         (funcall default-theme-fn)))
> (add-hook 'window-setup-hook (lambda () (funcall default-theme-fn)))
> =====
> 
> The `default-theme-fn' is just a wrapper function that `load-theme's my theme.
> 
> Earlier, on launching emacsclient, that function would get called after the frame loading finished.
> 
> But with the recent change, that function probably gets called before the frame loading has finished, and so
> the function is ineffective.
> 
> If I manually load my theme after the frame launches, I get my old theme back.
> 
> So, what should I replace `window-setup-hook' with that runs in both -nw mode and GUI mode emacsclient?

Emacs 27 has server-after-make-frame-function which you could use.

Re: Help using the right hook for loading theme on emacs daemon GUI

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 282 bytes --]

On Thu, Jan 17, 2019 at 4:50 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > So, what should I replace `window-setup-hook' with that runs in both -nw
> mode and GUI mode emacsclient?
>
> Emacs 27 has server-after-make-frame-function which you could use.
>

Thanks! That's good to know.

[-- Attachment #2: Type: text/html, Size: 598 bytes --]

Re: Help using the right hook for loading theme on emacs daemon GUI

[Phil Sainty]

On 2019-01-18 04:44, Kaushal Modi wrote:
> ;; Load the theme ONLY after the frame has finished loading (needed 
> especially
> ;; when running emacs in daemon mode)
> ;; 
> https://github.com/Malabarba/smart-mode-line/issues/84#issuecomment-46429893
> ;; ;; `after-make-frame-functions' hook is not run in no-window mode
> ;; (add-hook 'after-make-frame-functions (lambda (&rest frame)
> ;;                                         (funcall default-theme-fn)))

I'm not sure whether it's relevant in this case, but in general you
don't want to ignore the FRAME argument with after-make-frame-functions,
otherwise you don't know which frame is selected when your code is
evaluated.  e.g.:

(lambda (frame)
   (with-selected-frame frame
     ...))

Re: Help using the right hook for loading theme on emacs daemon GUI

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 764 bytes --]

Hi Phil,

On Thu, Jan 17, 2019 at 10:47 PM Phil Sainty <psainty@orcon.net.nz> wrote:

>
> I'm not sure whether it's relevant in this case, but in general you
> don't want to ignore the FRAME argument with after-make-frame-functions,
> otherwise you don't know which frame is selected when your code is
> evaluated.  e.g.:
>
> (lambda (frame)
>    (with-selected-frame frame
>      ...))
>

I'll keep that in mind. For the reason in that comment,
after-make-frame-functions did not work for me, so I had stopped using it.

Also, my workflow always uses only 1 frame. So there wasn't the problem of
selecting the frame (I think it selected the one and only frame then open
by default).

Though, it's good to know the right way of using that frame argument.

Thanks.

[-- Attachment #2: Type: text/html, Size: 1263 bytes --]

Re: Help using the right hook for loading theme on emacs daemon GUI

[Phil Sainty]

On 2019-01-23 09:27, Kaushal Modi wrote:
> Also, my workflow always uses only 1 frame. So there wasn't the
> problem of selecting the frame (I think it selected the one and only
> frame then open by default).

If you're running Emacs as a daemon, then (frame-list) might surprise 
you.

Likewise emacsclient --eval '(selected-frame)' when you've not yet
created a client frame.


-Phil

Re: Help using the right hook for loading theme on emacs daemon GUI

[Phil Sainty]

On 2019-01-23 09:27, Kaushal Modi wrote:
> For the reason in that comment, after-make-frame-functions did not
> work for me, so I had stopped using it.

Where the comment in question was:

;; `after-make-frame-functions' hook is not run in no-window mode

Which is a bit confusing to me.

If you are creating a new frame with the -nw option for an existing
Emacs instance then `after-make-frame-functions' definitely runs.
(Certainly in 26.1, where I just tested it.)

It's true that just running 'emacs -nw' does not run that hook for the
initial frame -- but then neither does it run for the initial frame
when you start 'emacs' in GUI mode, so the "no-window mode" part does
not seem relevant.

It's quite common to add a function to `after-make-frame-functions'
and to also call that function directly during init (or in
`after-init-hook' or some such) to process the initial frame.


-Phil

Re: Help using the right hook for loading theme on emacs daemon GUI

[Eli Zaretskii]

> Date: Thu, 24 Jan 2019 16:47:59 +1300
> From: Phil Sainty <psainty@orcon.net.nz>
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> It's true that just running 'emacs -nw' does not run that hook for the
> initial frame -- but then neither does it run for the initial frame
> when you start 'emacs' in GUI mode, so the "no-window mode" part does
> not seem relevant.

I think the comment is relevant, because in GUI mode we create a GUI
frame early during the startup and then delete the initial frame.  So
from the user's perspective, starting Emacs in GUI mode does run the
hook for the first frame displayed to the user.  The importance of
that should be obvious: users who want to have their initial
customizations triggered by this hook will not see them for the
initial displayed frame when starting Emacs in text mode.

Re: Help using the right hook for loading theme on emacs daemon GUI

[Phil Sainty]

On 2019-01-25 03:11, Eli Zaretskii wrote:
> I think the comment is relevant, because in GUI mode we create a GUI
> frame early during the startup and then delete the initial frame.  So
> from the user's perspective, starting Emacs in GUI mode does run the
> hook for the first frame displayed to the user.

I cannot replicate that in 26.1 or 27.  Init file contains:

(defun foo (frame)
   (message "%S => %S" (selected-frame) frame))

(add-hook 'after-make-frame-functions 'foo)

Starting a new emacs instance, whether GUI or -nw, does not generate
that message.

(I also tried substituting (debug) for the (message) call, and the
debugger was not triggered.)

What am I missing here?

(If it's running the hook, but it's happening before the init file
is processed, then that's surely a no-op for the purposes of this
question?)


-Phil

Re: Help using the right hook for loading theme on emacs daemon GUI

[Eli Zaretskii]

> Date: Fri, 25 Jan 2019 08:17:05 +1300
> From: Phil Sainty <psainty@orcon.net.nz>
> Cc: emacs-devel@gnu.org, kaushal.modi@gmail.com
> 
> On 2019-01-25 03:11, Eli Zaretskii wrote:
> > I think the comment is relevant, because in GUI mode we create a GUI
> > frame early during the startup and then delete the initial frame.  So
> > from the user's perspective, starting Emacs in GUI mode does run the
> > hook for the first frame displayed to the user.
> 
> I cannot replicate that in 26.1 or 27.  Init file contains:
> 
> (defun foo (frame)
>    (message "%S => %S" (selected-frame) frame))
> 
> (add-hook 'after-make-frame-functions 'foo)
> 
> Starting a new emacs instance, whether GUI or -nw, does not generate
> that message.
> 
> (I also tried substituting (debug) for the (message) call, and the
> debugger was not triggered.)
> 
> What am I missing here?

During startup this hook runs before the init file is loaded.  It is
called by this snippet from startup.el:

  ;; Under X, create the X frame and delete the terminal frame.
  (unless (daemonp)
    (if (or noninteractive emacs-basic-display)
	(setq menu-bar-mode nil
	      tool-bar-mode nil
	      no-blinking-cursor t))
    (frame-initialize))

> (If it's running the hook, but it's happening before the init file
> is processed, then that's surely a no-op for the purposes of this
> question?)

It's not entirely a no-op, since there's early-init-file and
package-initialize, both of which are called before this hook.

Re: Help using the right hook for loading theme on emacs daemon GUI

[Phil Sainty]

On 2019-01-25 08:44, Eli Zaretskii wrote:
> It's not entirely a no-op, since there's early-init-file and
> package-initialize, both of which are called before this hook.

Ah, interesting.  So this subtlety is new as of Emacs 27.

I was already thinking that the `after-make-frame-functions' docstring
could use some additional information (it seems to be a common point
of confusion when people start using --daemon); and even more so given
this new wrinkle.


(info "(elisp) Creating Frames") does already say:

>    Note that any functions added to these hooks by your initial file 
> are
> usually not run for the initial frame, since Emacs reads the initial
> file only after creating that frame.  However, if the initial frame is
> specified to use a separate minibuffer frame (*note Minibuffers and
> Frames::), the functions will be run for both, the minibuffer-less and
> the minibuffer frame.

(As a tangent, the terminology "initial file" instead of the more
common "init file" is a little jarring.  It crops up in that context
in a couple of other places in the manual, I see, and I'm unsure
whether it's a typo or intended, but I would be inclined to replace
them with "init file" in all cases.)

The info node should be updated to cover the new behaviour in 27, and
I suggest that the docstrings ought to provide a clear pointer to the
info node as being very important reading regarding when the hooks do
and do not run.  I think the docstrings should possibly also replicate
or summarise some of that information; but just ensuring that readers
know there are additional subtleties to understand, and where to read
about them, would be good enough.


-Phil

Re: Help using the right hook for loading theme on emacs daemon GUI

[Phil Sainty]

On 2019-01-25 10:16, Phil Sainty wrote:
> I was already thinking that the `after-make-frame-functions' docstring
> could use some additional information (it seems to be a common point
> of confusion when people start using --daemon)

I forgot to add -- the point I originally thought this docstring needed
to make was that FRAME will not be selected when the hook runs, and it 
is
up to the function to select it if required.

I'd be inclined to have the docstring suggest that the following be used
in that scenario:

(with-selected-frame FRAME
   ...)

This is rather more apparent when one looks at the documentation for
`make-frame' itself, but people won't necessarily feel the need to do
that; and while one can *guess* that this may be the case from the fact
that FRAME is being passed to the hook at all, I think it would be 
better
to make it explicit in the hook documentation.


-Phil

Re: Help using the right hook for loading theme on emacs daemon GUI

[Eli Zaretskii]

> Date: Fri, 25 Jan 2019 14:42:53 +1300
> From: Phil Sainty <psainty@orcon.net.nz>
> Cc: kaushal.modi@gmail.com, emacs-devel@gnu.org
> 
> I forgot to add -- the point I originally thought this docstring needed
> to make was that FRAME will not be selected when the hook runs, and it 
> is
> up to the function to select it if required.

Well, since FRAME is being passed as an argument to the hook, it
should be quite clear the frame is not selected, otherwise it would
make no sense to pass that argument, right?  But I see no harm in
saying that explicitly.

> I'd be inclined to have the docstring suggest that the following be used
> in that scenario:
> 
> (with-selected-frame FRAME
>    ...)

I wouldn't make this so explicit.  Selecting a frame affects Emacs in
significant ways, and the hook might not need that at all.  I think
saying that the frame is not selected should be enough; any Lisp
programmer can then decide for themselves whether they really need to
select the frame for whatever they need to do in the hook.

Re: Help using the right hook for loading theme on emacs daemon GUI

[Eli Zaretskii]

> Date: Fri, 25 Jan 2019 10:16:58 +1300
> From: Phil Sainty <psainty@orcon.net.nz>
> Cc: kaushal.modi@gmail.com, emacs-devel@gnu.org
> 
> I was already thinking that the `after-make-frame-functions' docstring
> could use some additional information (it seems to be a common point
> of confusion when people start using --daemon); and even more so given
> this new wrinkle.

Feel free to improve the docstring.  The existing one is really
minimal.

> >    Note that any functions added to these hooks by your initial file 
> > are
> > usually not run for the initial frame, since Emacs reads the initial
> > file only after creating that frame.  However, if the initial frame is
> > specified to use a separate minibuffer frame (*note Minibuffers and
> > Frames::), the functions will be run for both, the minibuffer-less and
> > the minibuffer frame.
> 
> (As a tangent, the terminology "initial file" instead of the more
> common "init file" is a little jarring.

I think it's a simple typo.  Someone, perhaps even myself, was using
"M-/" to minimize typing, and it picked up the wrong expansion.

> The info node should be updated to cover the new behaviour in 27, and
> I suggest that the docstrings ought to provide a clear pointer to the
> info node as being very important reading regarding when the hooks do
> and do not run.  I think the docstrings should possibly also replicate
> or summarise some of that information; but just ensuring that readers
> know there are additional subtleties to understand, and where to read
> about them, would be good enough.

Feel free to make the documentation better, by all means.  It is
usually hard to spot places in the manuals that need to be updated
because they are indirectly related to some change, without explicitly
referring to the symbols involved in the change.  So such inaccuracies
are usually discovered only when we proofread the manuals in
preparation for a release.  Which is why having such a proofreading
step is important.

Thanks.