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

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

[Chong Yidong]

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

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

[Drew Adams]

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

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

[Chong Yidong]

"Drew Adams" <drew.adams@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.

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.