bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame

bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame

[Óscar Fuentes]

Currently de docstrings of those variables do not mention that they are
not invoked for the initial frame. Adding that detail is trivial, except
that when the initial frame belongs to a daemon they are invoked.

I'm not sure how to word that information.


In GNU Emacs 27.0.50 (build 3, x86_64-pc-linux-gnu, X toolkit)
 of 2019-11-09 built on sky
Repository revision: f8284f1e408b38e6a3c0e2a1d5a465fefac6800a
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux bullseye/sid

bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame

[martin rudalics]

 > Currently de docstrings of those variables do not mention that they are
 > not invoked for the initial frame. Adding that detail is trivial, except
 > that when the initial frame belongs to a daemon they are invoked.
 >
 > I'm not sure how to word that information.

The reason is that the initial frame is not made by 'make-frame'.  The
Elisp manual says

      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.

This explanation is slightly misleading: Since the initial frame is
not created by 'make-frame', Emacs would not run these hooks even if
it did read the initial file earlier.  Hints for improving the
documentation are welcome.

martin

bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame

[Eli Zaretskii]

> From: martin rudalics <rudalics@gmx.at>
> Date: Sat, 9 Nov 2019 10:01:34 +0100
> 
>       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.
> 
> This explanation is slightly misleading: Since the initial frame is
> not created by 'make-frame', Emacs would not run these hooks even if
> it did read the initial file earlier.

But without an init file, where would the hooks come from?

And anyway, the issue is probably only meaningful for users who define
these hooks in init files.  So I think the only missing piece in the
above is to mention the daemon case.

bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>>       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.
>> 
>> This explanation is slightly misleading: Since the initial frame is
>> not created by 'make-frame', Emacs would not run these hooks even if
>> it did read the initial file earlier.
>
> But without an init file, where would the hooks come from?
>
> And anyway, the issue is probably only meaningful for users who define
> these hooks in init files.  So I think the only missing piece in the
> above is to mention the daemon case.

Please note that Martin is referring to the manual, not to the
docstrings. Although mentioning the daemon case on the manual would be
nice too.

IMO the missing information on the docstrings is:

1. The hooks are not run for the initial frame because it is not created
   with `make-frame'.

2. Except when Emacs runs as daemon, in that case make-frame is always
   used and therefore the hooks are executed.

The added text would be something like this:

  When Emacs is not executed as a daemon, `make-frame` is not used for
  creating the initial frame, therefore the hooks are not invoked on
  that case.

Or this:

  `make-frame` is not used for the frame that is automatically created
  before the init file is processed, therefore the hooks are not invoked
  for that frame. Please note that when Emacs is executed as a daemon
  there is no such frame.

bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame

[martin rudalics]

 > But without an init file, where would the hooks come from?

 From an early-init file.  IIUC that file is read before the initial
frame is created.

martin

bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame

[Eli Zaretskii]

> Cc: ofv@wanadoo.es, 38143@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Sun, 10 Nov 2019 10:45:50 +0100
> 
>  > But without an init file, where would the hooks come from?
> 
> From an early-init file.  IIUC that file is read before the initial
> frame is created.

I'm not sure I understand how this scenario affects the issue at hand
in any significant manner.

bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame

[martin rudalics]

 > I'm not sure I understand how this scenario affects the issue at hand
 > in any significant manner.

It doesn't.  It's a related issue I noticed when reading the manual.

martin

bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> 1. The hooks are not run for the initial frame because it is not created
>    with `make-frame'.
>
> 2. Except when Emacs runs as daemon, in that case make-frame is always
>    used and therefore the hooks are executed.
>
> The added text would be something like this:
>
>   When Emacs is not executed as a daemon, `make-frame` is not used for
>   creating the initial frame, therefore the hooks are not invoked on
>   that case.
>
> Or this:
>
>   `make-frame` is not used for the frame that is automatically created
>   before the init file is processed, therefore the hooks are not invoked
>   for that frame. Please note that when Emacs is executed as a daemon
>   there is no such frame.

I've now added something like this to Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  martin rudalics <rudalics@gmx.at>,
>   38143@debbugs.gnu.org
> Date: Sun, 05 Dec 2021 04:13:11 +0100
> 
> Óscar Fuentes <ofv@wanadoo.es> writes:
> 
> > 1. The hooks are not run for the initial frame because it is not created
> >    with `make-frame'.
> >
> > 2. Except when Emacs runs as daemon, in that case make-frame is always
> >    used and therefore the hooks are executed.
> >
> > The added text would be something like this:
> >
> >   When Emacs is not executed as a daemon, `make-frame` is not used for
> >   creating the initial frame, therefore the hooks are not invoked on
> >   that case.
> >
> > Or this:
> >
> >   `make-frame` is not used for the frame that is automatically created
> >   before the init file is processed, therefore the hooks are not invoked
> >   for that frame. Please note that when Emacs is executed as a daemon
> >   there is no such frame.
> 
> I've now added something like this to Emacs 29.

Bother:

   (defvar before-make-frame-hook nil
  -  "Functions to run before `make-frame' creates a new frame.")
  +  "Functions to run before `make-frame' creates a new frame.
  +Note that these functions are usually not run for the initial
  +frame, except when the initial frame is created from an Emacs
  +daemon.")

   (defvar after-make-frame-functions nil
     "Functions to run after `make-frame' created a new frame.
   The functions are run with one argument, the newly created
  -frame.")
  +frame.
  +
  +Note that these functions are usually not run for the initial
  +frame, except when the initial frame is created from an Emacs
  +daemon.")

The new text is incorrect -- assuming that by "initial frame" the doc
strings mean what we usually mean by that: the first frame displayed
by a GUI Emacs session (see "Frame Parameters" in the user manual, and
cf. initial-frame-alist).  You can put a breakpoint on Frun_hooks and
on Frun_hook_with_args, run Emacs, and see that both of these hooks
_are_ called during startup.  And the reason is simple: we do create
that "initial frame" via make-frame, see frame-initialize.

Perhaps the bug report was using "initial frame" in another sense: to
allude to the frame we create in temacs, which is a terminal frame,
normally deleted when a GUI session starts, except in a daemon, which
keeps it.  But in that case, these changes will confuse the heck out
of the users who will read them and try to figure out how to use this
information.  We should in that case explain in the doc strings which
"initial frame" we allude to here.

bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The new text is incorrect -- assuming that by "initial frame" the doc
> strings mean what we usually mean by that: the first frame displayed
> by a GUI Emacs session (see "Frame Parameters" in the user manual, and
> cf. initial-frame-alist).

OK; reverted.  Has this changed since the bug was reported?

> Perhaps the bug report was using "initial frame" in another sense: to
> allude to the frame we create in temacs, which is a terminal frame,
> normally deleted when a GUI session starts, except in a daemon, which
> keeps it.  But in that case, these changes will confuse the heck out
> of the users who will read them and try to figure out how to use this
> information.  We should in that case explain in the doc strings which
> "initial frame" we allude to here.

I think we need some input from the bug reported about what they meant
by "initial frame" here.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: ofv@wanadoo.es,  rudalics@gmx.at,  38143@debbugs.gnu.org
> Date: Sun, 05 Dec 2021 21:17:01 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The new text is incorrect -- assuming that by "initial frame" the doc
> > strings mean what we usually mean by that: the first frame displayed
> > by a GUI Emacs session (see "Frame Parameters" in the user manual, and
> > cf. initial-frame-alist).
> 
> OK; reverted.  Has this changed since the bug was reported?

The only relevant change I know of is that we now have early-init
file, which means users can set up these hooks there, and have them
run when the initial frame is created.

> > Perhaps the bug report was using "initial frame" in another sense: to
> > allude to the frame we create in temacs, which is a terminal frame,
> > normally deleted when a GUI session starts, except in a daemon, which
> > keeps it.  But in that case, these changes will confuse the heck out
> > of the users who will read them and try to figure out how to use this
> > information.  We should in that case explain in the doc strings which
> > "initial frame" we allude to here.
> 
> I think we need some input from the bug reported about what they meant
> by "initial frame" here.

Indeed.

bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> The new text is incorrect -- assuming that by "initial frame" the doc
>> strings mean what we usually mean by that: the first frame displayed
>> by a GUI Emacs session (see "Frame Parameters" in the user manual, and
>> cf. initial-frame-alist).
>
> OK; reverted.  Has this changed since the bug was reported?
>
>> Perhaps the bug report was using "initial frame" in another sense: to
>> allude to the frame we create in temacs, which is a terminal frame,
>> normally deleted when a GUI session starts, except in a daemon, which
>> keeps it.  But in that case, these changes will confuse the heck out
>> of the users who will read them and try to figure out how to use this
>> information.  We should in that case explain in the doc strings which
>> "initial frame" we allude to here.
>
> I think we need some input from the bug reported about what they meant
> by "initial frame" here.

I just tested with master and, indeed, the hook is executed. However, to
be effective for all invocations of make-frame the user must add the
function early enough (which means `early-init.el`.) When emacs.el is
processed it is too late as the initial frame (the frame created by
simply invoking emacs without parameters) already exists.

Maybe we could expand the docstrings of the hooks and/or make-frame to
note that you need early-init.el if you want your hooks executed when
the initial frame is created.

Otherwise, this bug can remain closed.

bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: Eli Zaretskii <eliz@gnu.org>,  rudalics@gmx.at,  38143@debbugs.gnu.org
> Date: Tue, 07 Dec 2021 00:22:50 +0100
> 
> > I think we need some input from the bug reported about what they meant
> > by "initial frame" here.
> 
> I just tested with master and, indeed, the hook is executed. However, to
> be effective for all invocations of make-frame the user must add the
> function early enough (which means `early-init.el`.) When emacs.el is
> processed it is too late as the initial frame (the frame created by
> simply invoking emacs without parameters) already exists.
> 
> Maybe we could expand the docstrings of the hooks and/or make-frame to
> note that you need early-init.el if you want your hooks executed when
> the initial frame is created.
> 
> Otherwise, this bug can remain closed.

Done and done.

Thanks.