unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Y. E. via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 50491@debbugs.gnu.org, monnier@iro.umontreal.ca
Subject: bug#50491: 28.0.50; load-theme in early-init does not fully loads/enables expected faces
Date: Sun, 12 Sep 2021 16:07:04 +0300	[thread overview]
Message-ID: <m2ilz6c58n.fsf@ego.team> (raw)
In-Reply-To: <83h7ergpb2.fsf@gnu.org> (message from Eli Zaretskii on Sat, 11 Sep 2021 17:27:45 +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.

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






  reply	other threads:[~2021-09-12 13:07 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-09 19:19 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
2021-09-10  5:53 ` Eli Zaretskii
2021-09-10 10:28   ` Y. E. via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-10 10:57     ` Eli Zaretskii
2021-09-10 16:32       ` yet--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-10 18:03         ` Eli Zaretskii
2021-09-11 14:19           ` yet--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-11 14:27             ` Eli Zaretskii
2021-09-12 13:07               ` Y. E. via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2021-09-12 13:21                 ` Eli Zaretskii
2021-09-14 15:08                   ` Y. E. via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-15 10:22                   ` bug#50491: [PATCH] " Y. E. via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-16 12:41                     ` Eli Zaretskii

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=m2ilz6c58n.fsf@ego.team \
    --to=bug-gnu-emacs@gnu.org \
    --cc=50491@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=yet@ego.team \
    /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).