GNU bug report logs - #3408
customize-face not working: seems to apply to frame-face

Previous Next

Full log

Message #28 received at 3408 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'David Reitter'" <david.reitter <at> gmail.com>,
        <3408 <at> debbugs.gnu.org>, "'Kenichi Handa'" <handa <at> m17n.org>
Subject: RE: bug#3408: customize-face not working: seems to apply to frame-face
Date: Thu, 28 May 2009 08:40:28 -0700

> > If the arg FRAME is nil, set-face-attribute changes
> > attributes on all frames plus the default for new frames
> >
> > But customize-face changes only the attributes of existing
> > frames.

If true, that's new. And horribly misguided. It totally redefines the meaning
and behavior of `customize-face'.

> > (customize-face 'default) ;; set :background back to "#ffffff"
> > (face-attribute 'default :background nil) => "#ffffff"
> > (face-attribute 'default :background t) => "gray"
> 
> So is this a new, intentional "feature"?
> 
> I presume there has been a discussion about this... because without  
> knowing the reasoning behind this, I'd say it was a bad call.  Very  
> confusing to users, who, by default, shouldn't be concerned 
> with frame-specific faces.  Note that even "save for future
> sessions" won't set the face for future frames.  How would I
> set a face through the customize interface that is valid for
> current and future frames?

I agree. What you describe is a terrible state of affairs.

Customize should *redefine* a face or option, giving it a new
behavior/appearance/value for now and for the future (session duration, unless
saved). 

If it does not do that - if it affects only existing *occurrences* (uses) of
faces (or options), then you have radically changed the meaning of Customize.

Customize is for changing user preferences, and those apply most importantly to
future use, not just to existing objects. If Customize becomes just about
repainting what's there already, then Customize is no longer about customizing.

If what is described is true (and IIUC), then to get the effect of the Emacs 22
(and 21...) behavior of changing the face definition for future frames also, you
will need to jump through hoops: save the changes, then restart Emacs. Then,
presumably, the preference change takes effect in the new session. And then you
would need to reset the face to what it was before, and resave, if you didn't
want that change to persist.

That is a ridiculous workaround, just to get a face change for future frames:
save, end the session, new session to get where you wanted to be. Then restore
the definition, save again, and exit, so your change lasted only for the
"macro-session" (split into two sessions, just for the workaround).

What was wrong with what we had before? What problem does this significant
change solve?

*Any* way of changing a face (or an option, for that matter) should affect it
for the future.

The question of whether the thing being customized is frame-specific is another
matter. If you customize a face, that should not be for some specific frame.
There should not be any notion of customization for a specific frame.
Customization should change the definition globally - for the session, unless
you save.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.