From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Faces applies to new frames Date: Fri, 27 Jun 2008 13:52:50 -0400 Message-ID: References: <87k5gbx12n.fsf@stupidchicken.com> <87prq3k37j.fsf@stupidchicken.com> <877icardfs.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1214589193 30011 80.91.229.12 (27 Jun 2008 17:53:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Jun 2008 17:53:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 27 19:53:59 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KCI8y-0005Fn-Fr for ged-emacs-devel@m.gmane.org; Fri, 27 Jun 2008 19:53:57 +0200 Original-Received: from localhost ([127.0.0.1]:43255 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KCI87-0006Nr-RQ for ged-emacs-devel@m.gmane.org; Fri, 27 Jun 2008 13:53:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KCI82-0006Lg-B5 for emacs-devel@gnu.org; Fri, 27 Jun 2008 13:52:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KCI81-0006Ju-Hz for emacs-devel@gnu.org; Fri, 27 Jun 2008 13:52:57 -0400 Original-Received: from [199.232.76.173] (port=56295 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KCI81-0006Jd-7z for emacs-devel@gnu.org; Fri, 27 Jun 2008 13:52:57 -0400 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]:40468 helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KCI80-0001ms-Q7 for emacs-devel@gnu.org; Fri, 27 Jun 2008 13:52:57 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwEAHTFZEhFxIdG/2dsb2JhbACBW7BqgXM X-IronPort-AV: E=Sophos;i="4.27,716,1204520400"; d="scan'208";a="23395915" Original-Received: from 69-196-135-70.dsl.teksavvy.com (HELO pastel.home) ([69.196.135.70]) by ironport2-out.teksavvy.com with ESMTP; 27 Jun 2008 13:52:51 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id F31DF801D; Fri, 27 Jun 2008 13:52:50 -0400 (EDT) In-Reply-To: <877icardfs.fsf@stupidchicken.com> (Chong Yidong's message of "Fri, 27 Jun 2008 13:32:39 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:100063 Archived-At: That's helpful, thanks. We need to put this info somewhere in the the CVS, as near the source as possible, but since the corresponding source code is scattered, we may as well put it elsewhere (and refer to it from the various relevant code sections). > Finternal_set_lisp_face_attribute (called by set-face-attribute) is > supposed to do two things: changes the face on existing frames, and (if > passed an integer FRAME argument) change the defaults for future frames. Hopefully Custom never calls it with an integer frame argument. > Currently, the latter is accomplished for only certain attributes: the > (default) foreground and background color, the default font, and the > colors for the border, cursor, scroll-bar, and mouse. These are saved > by modifying default-frame-alist. It does NOT modify > face-new-frame-defaults. Why doesn't change face-new-frame-defaults? Who does? > 1. Set the default face based on face-new-frame-defaults, via > face-attribute with a t FRAME argument. (It only does this if > inhibit-face-set-after-frame-default is nil, which may be bogus, > since that variable is only bound when doing set-face-attribute, > which does not create frames.) Yes, my recent change to fix the inf-recursion should make this variable useless. > 2. Walk through (face-list), applying defface specs to the rest of the > faces for this frame. > 3. Walk through (face-list), applying X resource settings to the rest > of the faces for this frame. > 4. Apply the frame parameter based face attributes describe above > (foreground and background color, the default font, and the colors > for the border, cursor, scroll-bar, and mouse). But this #4 seems wrong: if set-face-attribute stores global settings in those variables, then it means that step #4 will apply those global settings over the defface settings, which are per-terminal. > As a result, set-face-attribute does not seem to change attributes on > future frames, other than the foreground and background color, contrary > to the description of internal-set-lisp-face-attribute. Sounds like you're right ;-) > How about this: change internal-set-lisp-face-attribute so that its only > role is to change the faces on existing frames, leaving the frame > parameters alone. Then, handle the "saving for future frames" part in > the Lisp function set-face-attribute. Given that those settings are used/applied by Elisp code (in face-set-after-frame-default), I guess it makes sense to move that C code to Elisp code as you suggest: this will bring the producer and consumer into the same file, which can only be beneficial). > Maybe it should do this by > modifying face-new-frame-defaults and/or the defface spec. Updating the defface specs directly sounds attractive, but it might turn out to be difficult to do it right. Stefan