customize-face not working?

customize-face not working?

[David Reitter]

I wonder if this is a bug (GNU Emacs from Git repo, recent. NS port.):

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

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

[David Reitter]

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.

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

[Glenn Morris]

Perhaps this is relevant (I never understood it):

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

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

[Kenichi Handa]

In article <8625E304-B47B-42CF-B7EC-3A6926CE5C4F@gmail.com>, David Reitter <david.reitter@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@m17n.org

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

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

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?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

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

[Drew Adams]

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