From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#3408: customize-face not working: seems to apply to frame-face Date: Thu, 28 May 2009 08:40:28 -0700 Message-ID: References: <8625E304-B47B-42CF-B7EC-3A6926CE5C4F@gmail.com> <9A46C94D-EA2B-4721-9B22-4109C6E5085D@gmail.com> Reply-To: Drew Adams , 3408@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1243527418 19105 80.91.229.12 (28 May 2009 16:16:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 May 2009 16:16:58 +0000 (UTC) To: "'David Reitter'" , <3408@emacsbugs.donarmstrong.com>, "'Kenichi Handa'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 28 18:16:55 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1M9iHl-0002ZL-B9 for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 May 2009 18:16:53 +0200 Original-Received: from localhost ([127.0.0.1]:49128 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M9iHk-0000w0-IH for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 May 2009 12:16:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M9iAc-0003Lu-Ia for bug-gnu-emacs@gnu.org; Thu, 28 May 2009 12:09:30 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M9iAU-0003IN-Rg for bug-gnu-emacs@gnu.org; Thu, 28 May 2009 12:09:29 -0400 Original-Received: from [199.232.76.173] (port=37808 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M9iAU-0003IH-Mu for bug-gnu-emacs@gnu.org; Thu, 28 May 2009 12:09:22 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:40532) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M9iAT-00064h-H0 for bug-gnu-emacs@gnu.org; Thu, 28 May 2009 12:09:22 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n4SG9CO5007424; Thu, 28 May 2009 09:09:13 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n4SFo7Nw004204; Thu, 28 May 2009 08:50:07 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 28 May 2009 15:50:07 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 3408 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 3408-submit@emacsbugs.donarmstrong.com id=B3408.12435252413079 (code B ref 3408); Thu, 28 May 2009 15:50:07 +0000 Original-Received: (at 3408) by emacsbugs.donarmstrong.com; 28 May 2009 15:40:41 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n4SFebmL003067 for <3408@emacsbugs.donarmstrong.com>; Thu, 28 May 2009 08:40:38 -0700 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n4SFf8qH011316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 May 2009 15:41:09 GMT Original-Received: from abhmt010.oracle.com (abhmt010.oracle.com [141.146.116.19]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n4SFfFT2001034; Thu, 28 May 2009 15:41:15 GMT Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 May 2009 08:40:24 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <9A46C94D-EA2B-4721-9B22-4109C6E5085D@gmail.com> Thread-Index: AcnfRKN2qQKO7aPoTt+WCGJztUzmLgAX/zjA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt010.oracle.com [141.146.116.19] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4A1EB069.0101:SCFSTAT5015188,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Thu, 28 May 2009 12:09:29 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:28265 Archived-At: > > 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.