* bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame @ 2019-11-09 3:18 Óscar Fuentes 2019-11-09 9:01 ` martin rudalics 0 siblings, 1 reply; 13+ messages in thread From: Óscar Fuentes @ 2019-11-09 3:18 UTC (permalink / raw) To: 38143 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame 2019-11-09 3:18 bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame Óscar Fuentes @ 2019-11-09 9:01 ` martin rudalics 2019-11-09 9:27 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: martin rudalics @ 2019-11-09 9:01 UTC (permalink / raw) To: Óscar Fuentes, 38143 > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame 2019-11-09 9:01 ` martin rudalics @ 2019-11-09 9:27 ` Eli Zaretskii 2019-11-09 17:21 ` Óscar Fuentes 2019-11-10 9:45 ` martin rudalics 0 siblings, 2 replies; 13+ messages in thread From: Eli Zaretskii @ 2019-11-09 9:27 UTC (permalink / raw) To: martin rudalics; +Cc: ofv, 38143 > 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame 2019-11-09 9:27 ` Eli Zaretskii @ 2019-11-09 17:21 ` Óscar Fuentes 2021-12-05 3:13 ` Lars Ingebrigtsen 2019-11-10 9:45 ` martin rudalics 1 sibling, 1 reply; 13+ messages in thread From: Óscar Fuentes @ 2019-11-09 17:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 38143 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame 2019-11-09 17:21 ` Óscar Fuentes @ 2021-12-05 3:13 ` Lars Ingebrigtsen 2021-12-05 9:47 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Lars Ingebrigtsen @ 2021-12-05 3:13 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 38143 Ó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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame 2021-12-05 3:13 ` Lars Ingebrigtsen @ 2021-12-05 9:47 ` Eli Zaretskii 2021-12-05 20:17 ` Lars Ingebrigtsen 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2021-12-05 9:47 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: ofv, 38143 > 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame 2021-12-05 9:47 ` Eli Zaretskii @ 2021-12-05 20:17 ` Lars Ingebrigtsen 2021-12-05 20:21 ` Eli Zaretskii 2021-12-06 23:22 ` Óscar Fuentes 0 siblings, 2 replies; 13+ messages in thread From: Lars Ingebrigtsen @ 2021-12-05 20:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ofv, 38143 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame 2021-12-05 20:17 ` Lars Ingebrigtsen @ 2021-12-05 20:21 ` Eli Zaretskii 2021-12-06 23:22 ` Óscar Fuentes 1 sibling, 0 replies; 13+ messages in thread From: Eli Zaretskii @ 2021-12-05 20:21 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: ofv, 38143 > 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame 2021-12-05 20:17 ` Lars Ingebrigtsen 2021-12-05 20:21 ` Eli Zaretskii @ 2021-12-06 23:22 ` Óscar Fuentes 2021-12-07 17:58 ` Eli Zaretskii 1 sibling, 1 reply; 13+ messages in thread From: Óscar Fuentes @ 2021-12-06 23:22 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 38143 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame 2021-12-06 23:22 ` Óscar Fuentes @ 2021-12-07 17:58 ` Eli Zaretskii 0 siblings, 0 replies; 13+ messages in thread From: Eli Zaretskii @ 2021-12-07 17:58 UTC (permalink / raw) To: Óscar Fuentes; +Cc: larsi, 38143-done > 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame 2019-11-09 9:27 ` Eli Zaretskii 2019-11-09 17:21 ` Óscar Fuentes @ 2019-11-10 9:45 ` martin rudalics 2019-11-14 9:46 ` Eli Zaretskii 1 sibling, 1 reply; 13+ messages in thread From: martin rudalics @ 2019-11-10 9:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ofv, 38143 > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame 2019-11-10 9:45 ` martin rudalics @ 2019-11-14 9:46 ` Eli Zaretskii 2019-11-14 9:59 ` martin rudalics 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2019-11-14 9:46 UTC (permalink / raw) To: martin rudalics; +Cc: ofv, 38143 > 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame 2019-11-14 9:46 ` Eli Zaretskii @ 2019-11-14 9:59 ` martin rudalics 0 siblings, 0 replies; 13+ messages in thread From: martin rudalics @ 2019-11-14 9:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ofv, 38143 > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2021-12-07 17:58 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-11-09 3:18 bug#38143: 27.0.50; Say that before-make-frame-hook & after-make-frame-functions are not invoked for the initial frame Óscar Fuentes 2019-11-09 9:01 ` martin rudalics 2019-11-09 9:27 ` Eli Zaretskii 2019-11-09 17:21 ` Óscar Fuentes 2021-12-05 3:13 ` Lars Ingebrigtsen 2021-12-05 9:47 ` Eli Zaretskii 2021-12-05 20:17 ` Lars Ingebrigtsen 2021-12-05 20:21 ` Eli Zaretskii 2021-12-06 23:22 ` Óscar Fuentes 2021-12-07 17:58 ` Eli Zaretskii 2019-11-10 9:45 ` martin rudalics 2019-11-14 9:46 ` Eli Zaretskii 2019-11-14 9:59 ` martin rudalics
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).