unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Kangas <stefankangas@gmail.com>
Cc: public@beloved.name, emacs-devel@gnu.org
Subject: Re: Should https://www.gnu.org/software/emacs/manual/html_node/efaq/Fullscreen-mode-on-MS_002dWindows.html be renamed to Maxmize-mode-on-MS_002dWindows.html ?
Date: Sat, 21 Oct 2023 12:52:51 +0300	[thread overview]
Message-ID: <834jiks3nw.fsf@gnu.org> (raw)
In-Reply-To: <CADwFkmn15ebNHebDOie606KGkoDpiHMYkbuV8Hm=8PXcxvvUtw@mail.gmail.com> (message from Stefan Kangas on Sat, 21 Oct 2023 02:35:07 -0700)

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sat, 21 Oct 2023 02:35:07 -0700
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Next, the alternative solution does have a drawback, albeit a minor
> >> one: it uses early-init.el, something that is explicitly NOT
> >> recommended for display-related customizations.  It evidently works in
> >> this case, but advertising this in the FAQ flies in the face of our
> >> general recommendation not to do this kind of stuff there.
> >
> > Specifically, the Emacs user manual says:
> >
> >      We do not recommend that you move into ‘early-init.el’ customizations
> >   that can be left in the normal init files.  That is because the early
> >   init file is read before the GUI is initialized, so customizations
> >   related to GUI features will not work reliably in ‘early-init.el’.  By
> >   contrast, the normal init files are read after the GUI is initialized.
> >   If you must have customizations in the early init file that rely on GUI
> >   features, make them run off hooks provided by the Emacs startup, such as
> >   ‘window-setup-hook’ or ‘tty-setup-hook’.  *Note Hooks::.
> >
> > So I wonder whether we should advertise the suggested addition for
> > early-init file.  Stefan, WDYT?
> 
> I honestly don't know.  Do we foresee any issues with it?

Probably not with this specific one, but other customizations of
default-frame-alist could potentially have undesirable effects.

> BTW, how would one otherwise affect the default frame parameters, if not
> by adding it to "early-init.el"?  It seems like you have no choice but
> modify `default-frame-alist' before the first frame is created, if you
> want it to affect the first frame.  So perhaps doing it this way is "the
> right thing", even?

The startup code explicitly supports customization of
default-frame-alist in the "usual" user init files: it re-applies
default-frame-alist after the init files were loaded.  This whole
discussion is because some people don't like the momentary flash of
the initial frame without the customizations in default-frame-alist
applied, something that we had for decades without anyone complaining.

IOW, this is merely a minor visual annoyance, not a bug in Emacs.

> The above text speaks of "customizations related to GUI features", but
> doesn't give any examples.  I'm not an expert at that stuff, so it's
> hard for me to understand which features might be covered by that.
> Perhaps it's a small list that could be enumerated exhaustively, or
> perhaps it's basically everything with a few exceptions.

I'm okay with someone doing the job of collecting the problematic
settings.  Any takers?



  reply	other threads:[~2023-10-21  9:52 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-29 21:05 Should https://www.gnu.org/software/emacs/manual/html_node/efaq/Fullscreen-mode-on-MS_002dWindows.html be renamed to Maxmize-mode-on-MS_002dWindows.html ? David Hedlund
2023-09-30 13:57 ` Eli Zaretskii
2023-09-30 18:09   ` chad
2023-09-30 18:36     ` Eli Zaretskii
2023-09-30 19:06       ` David Hedlund
2023-09-30 19:21         ` Eli Zaretskii
2023-10-02 22:40           ` David Hedlund
2023-10-02 23:05             ` Emanuel Berg
2023-10-05  3:56               ` David Hedlund
2023-10-21  9:35           ` Stefan Kangas
2023-10-21  9:52             ` Eli Zaretskii [this message]
2023-10-21 10:02               ` Stefan Kangas
2023-10-21 11:18                 ` Eli Zaretskii
2023-10-21 20:05                 ` chad
2023-10-21 12:55             ` David Hedlund
2023-10-22 22:24               ` Stefan Kangas
2023-10-23 13:02                 ` Eli Zaretskii
2023-10-23 15:25                   ` David Hedlund
2023-10-23 15:33                   ` Stefan Kangas
2023-10-23 15:58                     ` David Hedlund
2023-10-28 17:25                       ` Stefan Kangas
2023-10-28 17:34                         ` Emanuel Berg
2023-10-28 18:51                           ` Eli Zaretskii
2023-10-28 19:39                             ` Emanuel Berg
2023-10-28 18:02                         ` David Hedlund
2023-10-28 20:03                           ` Stefan Kangas
2023-11-04 13:58                         ` Stefan Kangas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=834jiks3nw.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=public@beloved.name \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).