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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 3408 in the body.
You can then email your comments to 3408 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: David Reitter <david.reitter <at> gmail.com>
To: emacs-pretest-bug <at> gnu.org
Subject: customize-face not working: seems to apply to frame-face
Date: Wed, 27 May 2009 20:40:37 -0400

Emacs -Q

(set-face-attribute 'default nil
		    :height 130
		    :family "Lucida Grande")
;; switches default face

(customize-face 'default)
;; switch back manually to Monaco

(make-frame-command)  ;; C-x 5 2
;; the new frame is shown in the Lucida face.  Why?

The same thing works as I would expect in Emacs 22.  I would generally  
assume that `customize-face' applies to faces in future frames as well.

If this is no bug, I think an entry in NEWS under "Faces" would be  
appropriate....

Cc'ing Bob Halley who isolated this (but doesn't think it's a bug).


PS.: text-scale-mode is mentioned twice in NEWS.

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

From: Glenn Morris <rgm <at> gnu.org>
To: David Reitter <david.reitter <at> gmail.com>
Cc: 3408 <at> debbugs.gnu.org
Subject: Re: bug#3408: customize-face not working: seems to apply to frame-face
Date: Wed, 27 May 2009 21:12:41 -0400

Perhaps this is relevant (I never understood it):

http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00120.html

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

From: Kenichi Handa <handa <at> m17n.org>
To: David Reitter <david.reitter <at> gmail.com>, 3408 <at> debbugs.gnu.org
Subject: Re: bug#3408: customize-face not working: seems to apply to
 frame-face
Date: Thu, 28 May 2009 11:12:54 +0900

In article <8625E304-B47B-42CF-B7EC-3A6926CE5C4F <at> gmail.com>, David Reitter <david.reitter <at> gmail.com> writes:

> Emacs -Q
> (set-face-attribute 'default nil
> 		    :height 130
> 		    :family "Lucida Grande")
> ;; switches default face

> (customize-face 'default)
> ;; switch back manually to Monaco

> (make-frame-command)  ;; C-x 5 2
> ;; the new frame is shown in the Lucida face.  Why?

> The same thing works as I would expect in Emacs 22.  I would generally  
> assume that `customize-face' applies to faces in future frames as well.

This behaviour is not limitted to font related attributes.

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.

(face-attribute 'default :background nil) => "#ffffff"
(face-attribute 'default :background t) => unspecified

(set-face-attribute 'default nil :background "gray")

(face-attribute 'default :background nil) => "gray"
(face-attribute 'default :background t) => "gray"

(customize-face 'default) ;; set :background back to "#ffffff"

(face-attribute 'default :background nil) => "#ffffff"
(face-attribute 'default :background t) => "gray"

---
Kenichi Handa
handa <at> m17n.org

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

From: David Reitter <david.reitter <at> gmail.com>
To: Kenichi Handa <handa <at> m17n.org>
Cc: 3408 <at> debbugs.gnu.org
Subject: Re: bug#3408: customize-face not working: seems to apply to frame-face
Date: Wed, 27 May 2009 23:08:45 -0400

[Message part 1 (text/plain, inline)]

On May 27, 2009, at 10:12 PM, Kenichi Handa wrote:
> 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.

> (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?

[smime.p7s (application/pkcs7-signature, attachment)]

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: David Reitter <david.reitter <at> gmail.com>
Cc: 3408 <at> debbugs.gnu.org
Subject: Re: customize-face not working: seems to apply to frame-face
Date: Thu, 28 May 2009 00:53:20 -0400

> Emacs -Q
> (set-face-attribute 'default nil :height 130 :family "Lucida Grande")
> (customize-face 'default)
> (make-frame-command)  ;; C-x 5 2
>
> The same thing works as I would expect in Emacs 22.  I would generally
> assume that `customize-face' applies to faces in future frames as
> well.

Mixing set-face-attribute and Customize is a bad idea in general.

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.

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

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

> > Emacs -Q
> > (set-face-attribute 'default nil :height 130 :family 
> > "Lucida Grande") (customize-face 'default)
> > (make-frame-command)  ;; C-x 5 2
> >
> > The same thing works as I would expect in Emacs 22.  I 
> > would generally assume that `customize-face' applies to
> > faces in future frames as well.
> 
> Mixing set-face-attribute and Customize is a bad idea in general.

It *should not* be a bad idea - or, put as a question, why *should* it be a bad
idea? Logically, where is the problem? If the implementation is inadequate,
that's another matter, but where is the problem *logically*?

And what was wrong with the Emacs 22 behavior (implementation)?

If some feature was added for Emacs 23 that broke that behavior, and then you
say that things are too complex to use both `set-face-attribute' and Customize,
then back out that misguided feature until things can be done right. Things
seemed to be fine, before.

Adding some feature, no matter how worthy (multi-tty, Unicode), should not be an
excuse for breaking existing behavior, as if that were somehow inevitable
collateral damage.

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: <3408 <at> debbugs.gnu.org>,
        "'David Reitter'" <david.reitter <at> gmail.com>
Subject: Re: bug#3408: customize-face not working: seems to apply to frame-face
Date: Thu, 28 May 2009 13:08:18 -0400

"Drew Adams" <drew.adams <at> oracle.com> writes:

>> Mixing set-face-attribute and Customize is a bad idea in general.
>
> It *should not* be a bad idea - or, put as a question, why *should* it
> be a bad idea? Logically, where is the problem?

It's a bad idea in general because face computation has to take into
account subtle interactions between face-new-frame-defaults, defface
settings, X resources (which can be per-frame!), Customize, etc etc etc.
Between Emacs 21 and 22, and between Emacs 22 and 23, there have been
lots of changes in these subtle interactions, many of which are not easy
to explain.

I will take a look at this specific bug, and see if there is an
acceptable fix.  But my advice for the user is to settle on one single
method for changing faces, and stick to it.

In the long run, we need to figure out a way to simplify how faces are
computed, so that this kind of problem does not arise so easily.

Message #47 received at 3408 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> gnu.org>, "'David Reitter'" <david.reitter <at> gmail.com>
Cc: 3408 <at> debbugs.gnu.org, 3210 <at> debbugs.gnu.org
Subject: RE: bug#3210: face customization fails after set-face-attribute
Date: Sat, 9 Jun 2012 08:12:58 -0700

> > (set-face-attribute 'default nil :height 130 :family "Lucida Grande")
> > ;; modifies default face
> >
> > (customize-face 'default)
> > ;; switch back manually to Monaco and "set for current session"
> >
> > (make-frame-command)  ;; C-x 5 2
> > ;; the new frame is shown in Lucida.  Why?
> 
> I have edited the docstring of set-face-attribute, to make it clearer
> that this function overrides face specs.

Huh?  You baptize the bugged behvior as design by documenting it as intended?
No one intended or intends such behavior, AFAIK.  It is just an unfortunate,
unintended side effect of some implementation changes that someone made.  IOW, a
bug.

And why close bug #3408 at the same time?  That bugged behavior remains.  And it
is a regression from the behavior in Emacs 22 (and 21 and 20 and...).

As I said in the #3408 thread, and to which there was no reply: 

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

If you do not have the time now to fix a particular bug (a regression, no less),
then classify it as `wishlist'.  If you do not want to fix a bug, ever, then
classify it as `wont-fix'.

But please do not classify it for such reasons as `notabug'.  A bug is a bug.
It is not the same as intentional design.  Emacs Dev made implementation changes
in Emacs 23 that broke things.  If you will not fix them then `wont-fix' is the
right category.

Or if you really claim that this is a design change, then be clear to users:
document it generally for Customize:

  In the case of faces, Customize is about repainting what's
  there already.  It is not about customizing for the future.
  The advantages of this exception for faces are...

And add that design change to the NEWS (for Emacs 23), as a new "feature".

Message #60 received at 3408 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> gnu.org>, "'David Reitter'" <david.reitter <at> gmail.com>
Cc: 3408 <at> debbugs.gnu.org, 3210 <at> debbugs.gnu.org
Subject: RE: bug#3408: bug#3210: face customization fails after
	set-face-attribute
Date: Sat, 24 Nov 2012 20:52:07 -0800

Bug #3408 is a _regression_, and it has not been fixed.
A regression is certainly NOT `notabug'.

As I said on 2012-06-09:

> If you do not have the time now to fix a particular bug (a 
> regression, no less), then classify it as `wishlist'.
> If you do not want to fix a bug, ever, then classify it as
> `wont-fix'.
> 
> But please do not classify it for such reasons as `notabug'.  
> A bug is a bug.  It is not the same as intentional design.
> Emacs Dev made implementation changes in Emacs 23 that broke
> things.  If you will not fix them then `wont-fix' is the
> right category.
> 
> Or if you really claim that this is a design change, then be 
> clear to users: document it generally for Customize:
> 
>   In the case of faces, Customize is about repainting what's
>   there already.  It is not about customizing for the future.
>   The advantages of this exception for faces are...
> 
> And add that design change to the NEWS (for Emacs 23), as a 
> new "feature".

Message #65 received at 3408-done <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 'David Reitter' <david.reitter <at> gmail.com>, 3210 <at> debbugs.gnu.org,
	3408-done <at> debbugs.gnu.org
Subject: Re: bug#3408: bug#3210: face customization fails after
	set-face-attribute
Date: Sun, 25 Nov 2012 13:04:32 +0800

"Drew Adams" <drew.adams <at> oracle.com> writes:

> Bug #3408 is a _regression_, and it has not been fixed.
> A regression is certainly NOT `notabug'.

I disagree that this is a bug.  I have now taken another look at the
code, and my earlier conclusion stands.  Modifications to internal Lisp
faces (via set-face-attribute) take precedence over the effect of face
specs, so the behavior is working as intended and as documented
(including in the docstring of set-face-attribute).

The trunk now contains a change to face-spec-set which allows it to be
more easily called from Lisp code to override defface specs.  If you
want to modify faces from Lisp, use that rather than set-face-attribute.

Don't re-open this bug based on uninformed opinion.  Thanks.

Previous Next

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