* bug#3408: customize-face not working: seems to apply to frame-face
@ 2009-05-28 4:53 Chong Yidong
2009-05-28 15:40 ` Drew Adams
0 siblings, 1 reply; 8+ messages in thread
From: Chong Yidong @ 2009-05-28 4:53 UTC (permalink / raw)
To: David Reitter; +Cc: 3408
> 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#3408: customize-face not working: seems to apply to frame-face 2009-05-28 4:53 bug#3408: customize-face not working: seems to apply to frame-face Chong Yidong @ 2009-05-28 15:40 ` Drew Adams 2009-05-28 17:08 ` Chong Yidong 0 siblings, 1 reply; 8+ messages in thread From: Drew Adams @ 2009-05-28 15:40 UTC (permalink / raw) To: 'Chong Yidong', 3408, 'David Reitter' > > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#3408: customize-face not working: seems to apply to frame-face 2009-05-28 15:40 ` Drew Adams @ 2009-05-28 17:08 ` Chong Yidong 0 siblings, 0 replies; 8+ messages in thread From: Chong Yidong @ 2009-05-28 17:08 UTC (permalink / raw) To: Drew Adams; +Cc: 'David Reitter', 3408 "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. ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <AD8B1B64-DA4C-4FB1-8B1A-4A4E4FDD503C@gmail.com>]
* bug#3408: customize-face not working: seems to apply to frame-face [not found] <AD8B1B64-DA4C-4FB1-8B1A-4A4E4FDD503C@gmail.com> @ 2009-05-28 0:40 ` David Reitter 2009-05-28 1:12 ` Glenn Morris 2009-05-28 2:12 ` Kenichi Handa 0 siblings, 2 replies; 8+ messages in thread From: David Reitter @ 2009-05-28 0:40 UTC (permalink / raw) To: emacs-pretest-bug 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#3408: customize-face not working: seems to apply to frame-face 2009-05-28 0:40 ` David Reitter @ 2009-05-28 1:12 ` Glenn Morris 2009-05-28 2:12 ` Kenichi Handa 1 sibling, 0 replies; 8+ messages in thread From: Glenn Morris @ 2009-05-28 1:12 UTC (permalink / raw) To: David Reitter; +Cc: 3408 Perhaps this is relevant (I never understood it): http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00120.html ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#3408: customize-face not working: seems to apply to frame-face 2009-05-28 0:40 ` David Reitter 2009-05-28 1:12 ` Glenn Morris @ 2009-05-28 2:12 ` Kenichi Handa 2009-05-28 3:08 ` David Reitter 1 sibling, 1 reply; 8+ messages in thread From: Kenichi Handa @ 2009-05-28 2:12 UTC (permalink / raw) To: David Reitter, 3408 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#3408: customize-face not working: seems to apply to frame-face 2009-05-28 2:12 ` Kenichi Handa @ 2009-05-28 3:08 ` David Reitter 2009-05-28 15:40 ` Drew Adams 0 siblings, 1 reply; 8+ messages in thread From: David Reitter @ 2009-05-28 3:08 UTC (permalink / raw) To: Kenichi Handa; +Cc: 3408 [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#3408: customize-face not working: seems to apply to frame-face 2009-05-28 3:08 ` David Reitter @ 2009-05-28 15:40 ` Drew Adams 0 siblings, 0 replies; 8+ messages in thread From: Drew Adams @ 2009-05-28 15:40 UTC (permalink / raw) To: 'David Reitter', 3408, 'Kenichi Handa' > > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-05-28 17:08 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-05-28 4:53 bug#3408: customize-face not working: seems to apply to frame-face Chong Yidong 2009-05-28 15:40 ` Drew Adams 2009-05-28 17:08 ` Chong Yidong [not found] <AD8B1B64-DA4C-4FB1-8B1A-4A4E4FDD503C@gmail.com> 2009-05-28 0:40 ` David Reitter 2009-05-28 1:12 ` Glenn Morris 2009-05-28 2:12 ` Kenichi Handa 2009-05-28 3:08 ` David Reitter 2009-05-28 15:40 ` Drew Adams
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).