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

[Eli Zaretskii <eliz@gnu.org>]

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