bug#77928: Regression in Emacs pretest 31.0.90

> From: Roshan Shariff <[email protected]>
> Date: Sun, 26 Jul 2026 13:44:20 -0600
> Cc: [email protected], [email protected], [email protected], 
> 	[email protected]
> 
> On Sat, 25 Jul 2026 at 22:48, Eli Zaretskii <[email protected]> wrote:
> > > If the face spec is recalculated for any reason, your changes are
> > > lost.
> >
> > As they should be, IMO
> 
> I'm afraid this can't serve the intended purpose of :custom-face,
> which it actually did before this patch.

Which is the original sin, IMNSHO.  It could be that we are forever
stuck with this, but that doesn't mean we need to like it, and we
might as well choose to refrain from fixing problems that are caused
by this particular implementation.

> A use-package declaration,
> just like the auto-generated custom-set-faces form, executes exactly
> once: at init time. Whereas changing themes can happen any time, for
> example by calling load-theme interactively (to switch from a light to
> dark theme, say). That's why all these customization facilities are
> declarative forms that save the user's preference in some
> variable/property and then apply it whenever themes are changed.

I see no reason whatsoever to expect :custom-face to keep being in
effect after a theme is loaded.  If the user wants :custom-face to
take precedence, he/she should use :custom-face _after_ loading a
theme in their init file.  And if a theme is loaded manually, it is
completely okay, from my POV, for it to override all the previous face
customizations.

> On the other hand, set-face-attributes is the lower-level imperative
> mechanism that these declarative forms use to actually apply the face
> attributes they've computed. If, as you suggest, :custom-face were to
> desugar to set-face-attributes, then the only way for a user to
> re-apply their preference after changing themes would be to open their
> init file and explicitly re-evaluate the use-package block.

Or use one of the commands that set various face properties, yes.  As
I mentioned above, I see no problem in this.

> > What you seem to want to do is possible via custom-set-faces.  But
> > mixing :custom-face and custom-set-faces is known (and documented) to
> > produce confusing results, so my conclusion is that we shouldn't make
> > :custom-face work like custom-set-faces, or else we will be
> > encouraging the confusing results against which we ourselves warn.
> 
> This entire discussion is because custom-set-faces is not an adequate
> replacement either. If it were, we could just desugar :custom-face to
> a call to custom-set-faces and call it a day. Instead, we want the
> semantics of custom-set-faces with respect to applying customizations,
> but we don't want to participate in the auto-persistence
> functionality. Indeed, the use-package form has already been saved by
> the user in their init file, so there's no reason for Emacs to worry
> about saving it again by automagically editing the custom-file. That's
> where custom-set-faces falls down, since it's really only meant to be
> called from that auto-generated custom-file section, if you use it
> directly from elsewhere in your init file, that customization will be
> duplicated into the auto-generated section (and cause really confusing
> issues).
> 
> The goal is not to allow mixing custom-set-faces with :custom-file;
> the latter is a replacement for the former, with the same
> functionality sans auto-persistence. But, of course, since we can't
> prevent the user from using both, we should define something
> reasonable to happen if they do.

You lost me here, sorry.

And I really don't see any reasons to keep this argument, where it is
clear we disagree about fundamental issues, and no one else feels it's
important enough to chime in.