bug#50491: 28.0.50; load-theme in early-init does not fully loads/enables expected faces

bug#50491: 28.0.50; load-theme in early-init does not fully loads/enables expected faces

[Y. E. via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hello,

I've been using (load-theme 'misterioso t) in early-init.el successfully
up until around one month ago. After that, I had to start calling load-theme
for the second time in init.el to fix appearance of wrong faces.

**How to Reproduce**

1. Backup `~/.emacs.d/'.
2. Create `~/.emacs.d/early-init.el' with `(load-theme 'misterioso t)' in it.
3. Start Emacs.
4. Run `M-x list-faces-display`.
5. Make new frame `C-x 5 2'.
6. Run `M-x list-faces-display' in the second frame.
7. Compare `*Faces*' buffer contents in the first and the second frames.
   - The correct 'misterioso theme faces are shown in the second buffer.
   - For example, compare `completions-common-part'.

Then go back to the first frame and run/evaluate `(load-theme 'misterioso)'.
The faces are going to be fixed in the first frame after that.

It _seems_ to me the issue _might be_ caused by the interference of the "user theme"
mentioned in `(emacs) 49.1.8 Creating Custom Themes'.
[This insinuation was caused by seeing `user' theme as one of the options
on `M-x enable-theme' with `fido-mode' enabled,
which, supposedly, might be a bug on its own.]

Thank you.

In GNU Emacs 28.0.50 (build 11, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G9216))
 of 2021-09-05 built on local
Repository revision: 3d0276e98bd2e31c45592def9f53da031a1ae277
Repository branch: master

Configured using:
 'configure LDFLAGS=-L/usr/local/opt/flex/lib
 CPPFLAGS=-I/usr/local/opt/flex/include'

Configured features:
ACL GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER
PNG THREADS TIFF TOOLKIT_SCROLL_BARS ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Org

Minor modes in effect:
  flyspell-mode: t
  windmove-mode: t
  global-goto-address-mode: t
  goto-address-mode: t
  company-mode: t
  icomplete-mode: t
  fido-mode: t
  savehist-mode: t
  desktop-save-mode: t
  delete-selection-mode: t
  global-hi-lock-mode: t
  hi-lock-mode: t
  electric-pair-mode: t
  show-paren-mode: t
  global-auto-revert-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-save-visited-mode: t

Load-path shadows:
None found.

Features:
(shadow sort display-fill-column-indicator mail-extr emacsbug
flymake-proc flymake compile warnings flyspell ol-eww eww xdg url-queue
mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect gnus-search
eieio-opt cl-extra help-mode speedbar ezimage dframe gnus-art mm-uu
mml2015 mm-view mml-smime smime dig gnus-sum shr kinsoku svg dom
gnus-group gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud nnimap
nnmail mail-source utf7 netrc nnoo parse-time gnus-spec gnus-int
gnus-range gnus-win gnus nnheader ol-docview doc-view jka-compr
image-mode exif ol-bibtex bibtex iso8601 ol-bbdb ol-w3m windmove
cus-edit cus-load wid-edit bookmark pp vc-git diff-mode vc-dispatcher
goto-addr thingatpt ox-odt rng-loc rng-uri rng-parse rng-match rng-dt
rng-util rng-pttrn nxml-parse nxml-ns nxml-enc xmltok nxml-util ox-latex
ox-icalendar ox-html table ox-ascii ox-publish ox org-element avl-tree
generator whitespace company-dabbrev-code company-dabbrev company pcase
smtpmail sendmail rmailout rmailmm message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived gnus-util text-property-search mm-decode
mm-bodies mm-encode mailabbrev gmm-utils mailheader mail-parse rfc2231
rmailsum rmail rmail-loaddefs rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils org ob ob-tangle ob-ref ob-lob ob-table ob-exp
org-macro org-footnote org-src ob-comint org-pcomplete pcomplete comint
ansi-color ring org-list org-faces org-entities time-date noutline
outline easy-mmode org-version ob-emacs-lisp ob-core ob-eval org-table
ol org-keys org-compat advice org-macs org-loaddefs format-spec
find-func cal-menu calendar cal-loaddefs icomplete ido savehist
minibuf-eldef desktop frameset ispell rx epg rfc6068 epg-config delsel
hi-lock elec-pair paren autorevert filenotify edmacro kmacro info
package browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib misterioso-theme iso-transl
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar
mouse jit-lock font-lock syntax font-core term/tty-colors frame
minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite charscript charprop case-table epa-hook jka-cmpr-hook help
simple abbrev obarray cl-preloaded nadvice button loaddefs faces
cus-face macroexp files window text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote threads kqueue cocoa ns lcms2 multi-tty make-network-process
emacs)

Memory information:
((conses 16 273685 17345)
 (symbols 48 26762 3)
 (strings 32 94932 6500)
 (string-bytes 1 3122713)
 (vectors 16 49630)
 (vector-slots 8 526459 11142)
 (floats 8 307 553)
 (intervals 56 469 88)
 (buffers 992 13))

bug#50491: 28.0.50; load-theme in early-init does not fully loads/enables expected faces

[Eli Zaretskii]

> Date: Thu, 09 Sep 2021 22:19:06 +0300
> From:  "Y. E." via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> I've been using (load-theme 'misterioso t) in early-init.el successfully
> up until around one month ago. After that, I had to start calling load-theme
> for the second time in init.el to fix appearance of wrong faces.

If you load themes only in init.el, once, without loading them in
early-init.el, does the problem go away?

The early-init file is not meant to support every single
customization of Emacs, only those that must be done before loading
init.el.  So if this works in init.el, then there's no bug here.

bug#50491: 28.0.50; load-theme in early-init does not fully loads/enables expected faces

[Y. E. via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi Eli,

> If you load themes only in init.el, once, without loading them in
> early-init.el, does the problem go away?

It is now, though I used to see "blinking" (white background showing up for
a second before a dark theme load) on Emacs startup with the theme
loaded/enabled in init.el.
Probably I saw it on one of the previously compiled Emacs versions.

> The early-init file is not meant to support every single
> customization of Emacs, only those that must be done before loading
> init.el.

Sure. I thought it might be a bug because a theme used to be loaded
correctly from early-init.el up until some (past) moment.

One question though.
`(emacs)49.4.6 The Early Init File' says:
"you can customize variables that affect frame appearance"
and
"customizations related to GUI features will not work reliably"

"frame appearance" and "GUI features" to my _naїve_ eyes _seem_
a bit contradictory.
Could probably documentation be clarified saying more on what exactly
is (not)supported in the early-init file?

For instance, which of these expressions are fine to be early-loaded:
`default-frame-alist', `initial-frame-alist', `inhibit-startup-message',
`initial-scratch-message', `scroll-bar-mode', `tool-bar-mode'?


> So if this works in init.el, then there's no bug here.

I'm fine with that since it works for me now with init.el.


Thank you,
YE

bug#50491: 28.0.50; load-theme in early-init does not fully loads/enables expected faces

[Eli Zaretskii]

> From: "Y. E." <yuga@ego.team>
> Cc: yet@ego.team, 50491@debbugs.gnu.org
> Date: Fri, 10 Sep 2021 13:28:49 +0300
> 
> One question though.
> `(emacs)49.4.6 The Early Init File' says:
> "you can customize variables that affect frame appearance"
> and
> "customizations related to GUI features will not work reliably"
> 
> "frame appearance" and "GUI features" to my _naїve_ eyes _seem_
> a bit contradictory.
> Could probably documentation be clarified saying more on what exactly
> is (not)supported in the early-init file?

I'm not sure this is feasible in practice.  The general advice is not
to customize in early-init stuff that can be customized in init.el.
Any more detailed description runs the risk of describing side-effects
of implementation details, which are therefore "subject to change
without notice".

bug#50491: 28.0.50; load-theme in early-init does not fully loads/enables expected faces

[yet--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> > `(emacs)49.4.6 The Early Init File' says:
> > "you can customize variables that affect frame appearance"
> > and
> > "customizations related to GUI features will not work reliably"
> >
> > "frame appearance" and "GUI features" to my _naїve_ eyes _seem_
> > a bit contradictory.
> > Could probably documentation be clarified saying more on what exactly
> > is (not)supported in the early-init file?

> I'm not sure this is feasible in practice.  The general advice is not
> to customize in early-init stuff that can be customized in init.el.
> Any more detailed description runs the risk of describing side-effects
> of implementation details, which are therefore "subject to change
> without notice".

Yes, I understand.

Let's look at it at a bit different angle then,
to make sure there's really nothing to change in the documentation:

The documentation page 49.4.6 mentions that in early-init.el
we can customize two things:
1. "frame appearance".
2. "package initialization process".

After that, documentation goes into details on which exactly variables
can (for example) be customized for the goal of "package initialization
process". (4 variables are mentioned.)

Then it is said that "GUI features will not work reliably in early-init",
which leaves in me (then, potentially, in somebody else too) a cognitive
dis-balance (confusion), by contrasting with the phrase "frame appearance"
from the previous paragraph.

So I suggest considering (one of) the following changes:

- Clarify what "frame appearance" means (to distinguish from - probably
more abstract - term "GUI").

- Change word "appearance" to whatever is appropriate but doesn't
cause "GUI" connotations.

- Maybe provide a couple of example variables for "frame appearance",
similar to "package initialization process" examples. (If possible, of course).
  - My own assumption was I could "safely" use `default-frame-alist' and
  `initial-frame-alist' in early-init, but now I'm not sure.

- Or even remove "frame appearance" mentioning if it shouldn't be there
due to the reasoning given in the previous email (cited above).

- Maybe list all the variables that are surely supported and say more
definitively that anything not on that list are "subject to change
without notice".


Thank you for your work and for looking into it.

YE

bug#50491: 28.0.50; load-theme in early-init does not fully loads/enables expected faces

[Eli Zaretskii]

> From: yet@ego.team
> Cc: yet@ego.team, 50491@debbugs.gnu.org
> Date: Fri, 10 Sep 2021 19:32:40 +0300
> 
> > I'm not sure this is feasible in practice.  The general advice is not
> > to customize in early-init stuff that can be customized in init.el.
> > Any more detailed description runs the risk of describing side-effects
> > of implementation details, which are therefore "subject to change
> > without notice".
> 
> Yes, I understand.
> 
> Let's look at it at a bit different angle then,
> to make sure there's really nothing to change in the documentation:
> 
> The documentation page 49.4.6 mentions that in early-init.el
> we can customize two things:
> 1. "frame appearance".
> 2. "package initialization process".
> 
> After that, documentation goes into details on which exactly variables
> can (for example) be customized for the goal of "package initialization
> process". (4 variables are mentioned.)
> 
> Then it is said that "GUI features will not work reliably in early-init",
> which leaves in me (then, potentially, in somebody else too) a cognitive
> dis-balance (confusion), by contrasting with the phrase "frame appearance"
> from the previous paragraph.
> 
> So I suggest considering (one of) the following changes:
> 
> - Clarify what "frame appearance" means (to distinguish from - probably
> more abstract - term "GUI").
> 
> - Change word "appearance" to whatever is appropriate but doesn't
> cause "GUI" connotations.
> 
> - Maybe provide a couple of example variables for "frame appearance",
> similar to "package initialization process" examples. (If possible, of course).
>   - My own assumption was I could "safely" use `default-frame-alist' and
>   `initial-frame-alist' in early-init, but now I'm not sure.
> 
> - Or even remove "frame appearance" mentioning if it shouldn't be there
> due to the reasoning given in the previous email (cited above).
> 
> - Maybe list all the variables that are surely supported and say more
> definitively that anything not on that list are "subject to change
> without notice".

We already say there:

     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 it seems we already warn there against moving initializations to
early-init.el that can be left in init.el.  I see no reason to have a
more detailed warning.

bug#50491: 28.0.50; load-theme in early-init does not fully loads/enables expected faces

[yet--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> We already say there:

>      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
> ...

> So it seems we already warn there against moving initializations to
> early-init.el that can be left in init.el.  I see no reason to have a
> more detailed warning.

That's right, I'm fine with that part.
What confuses me is the phrase "frame appearance".
(The concerns I have/had were described in more detail in my previous
email.)

It makes me guess if probably any of the documented
`(elisp) 30.4 Frame Parameters' variables could be added
to the early-init file quite "safely"?

[I took a look at the commit 6dfdf0c9e8e that added that phrase but,
unfortunately, it didn't answer my question.]

Thank you.

bug#50491: 28.0.50; load-theme in early-init does not fully loads/enables expected faces

[Eli Zaretskii]

> From: yet@ego.team
> Cc: 50491@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 11 Sep 2021 17:19:13 +0300
> 
> 
> > We already say there:
> 
> >      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
> > ...
> 
> > So it seems we already warn there against moving initializations to
> > early-init.el that can be left in init.el.  I see no reason to have a
> > more detailed warning.
> 
> That's right, I'm fine with that part.
> What confuses me is the phrase "frame appearance".

That could mean any number of things, and it is unreasonable to start
listing them, because the list will very quickly become outdated, aswe
add/change stuff in Emacs.

> It makes me guess if probably any of the documented
> `(elisp) 30.4 Frame Parameters' variables could be added
> to the early-init file quite "safely"?

I don't know, but why would you need to do that in early-init?  AFAIR,
startup.el already has all the necessary smarts to DTRT when the
user's init file changes frame parameters, so you shouldn't need to
move that into early-init file.  If you have specific problems with
changing them in the normal init files, please tell the details.

bug#50491: 28.0.50; load-theme in early-init does not fully loads/enables expected faces

[Y. E. via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> > > We already say there:
> >
> > >      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
> > > ...
> >
> > > So it seems we already warn there against moving initializations to
> > > early-init.el that can be left in init.el.  I see no reason to have a
> > > more detailed warning.
> >
> > That's right, I'm fine with that part.
> > What confuses me is the phrase "frame appearance".

> That could mean any number of things, and it is unreasonable to start
> listing them, because the list will very quickly become outdated, aswe
> add/change stuff in Emacs.

I totally agree.
That's why I optionally suggested the removal of the phrase
"frame appearance as well as" when listed possible improvements
for this documentation page.

Unless there's an exact reason to keep the phrase which, seems,
contradicts (or is an exception) to the rest of the documentation,
starting with "We do not recommend that you move into early-init...".

If "frame appearance" *is* an exception, then clarification
would still be a preferred approach in my opinion.

I CC'd Stefan Monnier whose commit added that phrase to
`(emacs) 49.4.6 The Early Init File', so might be he'd be able to
shed some light on it.

> > It makes me guess if probably any of the documented
> > `(elisp) 30.4 Frame Parameters' variables could be added
> > to the early-init file quite "safely"?

> I don't know, but why would you need to do that in early-init?
> AFAIR,
> startup.el already has all the necessary smarts to DTRT when the
> user's init file changes frame parameters, so you shouldn't need to
> move that into early-init file.  If you have specific problems with
> changing them in the normal init files, please tell the details.

*1st Case*
For example, moving `initial-frame-alist' out of early-init
leads to the geometry and font of the initial frame being changed during startup
(it loads as a small frame first, then expands according to my settings),
which is an aesthetically unpleasant behavior.

The expression I use:

(setq initial-frame-alist
      `((top . 0.0)
        (left . 0.0)
        (width . 0.52)
        (height . 1.0)
        (font . ,os-font))) ; f.i. "Monaco-17"

*2nd Case*
Also, while moving all the settings out of the early-init file,
I reproduced the white-background-blinking on Emacs startup
mentioned before
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50491#14

Namely,
> I used to see "blinking" (white background showing up for
> a second before a dark theme load) on Emacs startup with the theme
> loaded/enabled in init.el.

To reproduce this behavior I put `(scroll-bar-mode -1)' at the first line
of the init.el file, then load few small configuration files,
then load a small file with the line (load-theme 'misterioso t).

The more lines of code are loaded between the calls of
`scroll-bar-mode' and `load-theme', the longer I see Emacs loading with
the white background (instead of seeing the theme's background).

One of the following fixes the issue:
- Place `(scroll-bar-mode -1)' *after* the (load-theme 'misterioso t) line.
- Put `(scroll-bar-mode -1)' to the early-init.el file.


Thanks.
YE

bug#50491: 28.0.50; load-theme in early-init does not fully loads/enables expected faces

[Eli Zaretskii]

> From: Y. E. <yet@ego.team>
> Cc: 50491@debbugs.gnu.org, monnier@iro.umontreal.ca
> Date: Sun, 12 Sep 2021 16:07:04 +0300
> 
> > That could mean any number of things, and it is unreasonable to start
> > listing them, because the list will very quickly become outdated, aswe
> > add/change stuff in Emacs.
> 
> I totally agree.
> That's why I optionally suggested the removal of the phrase
> "frame appearance as well as" when listed possible improvements
> for this documentation page.

But that phrase isn't incorrect: some of the parameters _can_ be set
in the early-init file.  I'm just saying don't do that unless you
really have to, i.e. unless having it in the init files completely
doesn't work.

> For example, moving `initial-frame-alist' out of early-init
> leads to the geometry and font of the initial frame being changed during startup
> (it loads as a small frame first, then expands according to my settings),
> which is an aesthetically unpleasant behavior.

"Aesthetically unpleasant" is not a reason to move stuff into
early-init.  What you see is startup.el in action: it detects that
display parameters have changed, and it applies them.

> Also, while moving all the settings out of the early-init file,
> I reproduced the white-background-blinking on Emacs startup
> mentioned before
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50491#14

Same thing: as long as it works, leave it alone.

> The more lines of code are loaded between the calls of
> `scroll-bar-mode' and `load-theme', the longer I see Emacs loading with
> the white background (instead of seeing the theme's background).

That's the expected and the correct behavior.  By contrast, moving
this stuff to early-init will bite you eventually.  I don't recommend
it, and I don't see any bug here that needs to be fixed.

> One of the following fixes the issue:
> - Place `(scroll-bar-mode -1)' *after* the (load-theme 'misterioso t) line.
> - Put `(scroll-bar-mode -1)' to the early-init.el file.

My recommendation is to use the former.

bug#50491: 28.0.50; load-theme in early-init does not fully loads/enables expected faces

[Y. E. via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Thank you for the recommendations, Eli.

Please keep this report open for now.

I'd like to try writing/sending a patch with possible documentation
improvements based on some of the wonderfully formulated sentences you
responded with.

If I don't find (compose) better wording, I'll close this thread pretty soon.

bug#50491: [PATCH] Re: bug#50491: 28.0.50; load-theme in early-init does not fully loads/enables expected faces

[Y. E. via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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


Suggested changes:

1.
> The early-init file is not meant to support every single
> customization of Emacs, only those that must be done before loading
> init.el.

Then I suggest replacing "desirable" with "necessary" or a similar word
with the meaning "cannot avoid".

2.
Optionally, consider adjusting the wording at the beginning of the second
paragraph.
It sounded perfect until the later commit 4118297ae2f added an intro phrase
(an extracted version of the second paragraph).
Current getting back to the same topic, after discussing another detail
in the mid, without reference to the already expressed idea breaks smooth
perception.

****
Regardless of the changes, please let me know if the patch formatted/sent
the way you'd normally would expect (prefer) it to be done.
I followed CONTRIBUTE guidelines (the file contains a lot of information,
so I might have missed something), used 'git format-patch', and sent
the patch as an attachment via Rmail ('C-c C-a').

Particularly:
The patch itself seems got a whitespace added at the end of file,
even though there's no such whitespace in the diff/commit I have locally.
Is it expected behavior?

Thank you.



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: ; * doc/emacs/custom.texi (Early Init): Improve wording (Bug#50491) --]
[-- Type: text/x-patch, Size: 1502 bytes --]

From 1821e64673e86565ab870bc4ff6f8d897c2ea2cf Mon Sep 17 00:00:00 2001
From: YE <yet@ego.team>
Date: Wed, 15 Sep 2021 12:23:15 +0300
Subject: [PATCH] ; * doc/emacs/custom.texi (Early Init): Improve wording
 (Bug#50491)

---
 doc/emacs/custom.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/emacs/custom.texi b/doc/emacs/custom.texi
index 9220a2078f..564393e17e 100644
--- a/doc/emacs/custom.texi
+++ b/doc/emacs/custom.texi
@@ -2807,7 +2807,7 @@ Early Init File
 @cindex early init file
 
   Most customizations for Emacs should be put in the normal init file.
-@xref{Init File}.  However, it is sometimes desirable
+@xref{Init File}.  However, it is sometimes necessary
 to have customizations that take effect during Emacs startup earlier than the
 normal init file is processed.  Such customizations can be put in the early
 init file, @file{~/.config/emacs/early-init.el} or @file{~/.emacs.d/early-init.el}.  This file is loaded before the
@@ -2819,7 +2819,7 @@ Early Init File
 making already-installed packages available, may be customized in the regular
 init file.  @xref{Package Installation}.
 
-  We do not recommend that you move into @file{early-init.el}
+  We emphasize again, that it is not recommended to move into @file{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
-- 
2.30.0

bug#50491: [PATCH] Re: bug#50491: 28.0.50; load-theme in early-init does not fully loads/enables expected faces

[Eli Zaretskii]

> From: Y. E. <yet@ego.team>
> Cc: yet@ego.team, 50491@debbugs.gnu.org
> Date: Wed, 15 Sep 2021 13:22:34 +0300
> 
> Suggested changes:

Thanks, I installed a variant of this.

> Regardless of the changes, please let me know if the patch formatted/sent
> the way you'd normally would expect (prefer) it to be done.

The patch is formatted correctly, thanks.

> The patch itself seems got a whitespace added at the end of file,
> even though there's no such whitespace in the diff/commit I have locally.
> Is it expected behavior?

It doesn't matter, Git disregards that when applying the patch.