emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Should https://www.gnu.org/software/emacs/manual/html_node/efaq/Full


From: Eli Zaretskii
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

> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]