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: Sun, 29 Jun 2008 14:00:46 -0400 Message-ID: References: <87k5gbx12n.fsf@stupidchicken.com> <87iqvty2e7.fsf@stupidchicken.com> <871w2hcek1.fsf@stupidchicken.com> <87wsk8kgm5.fsf@stupidchicken.com> <87prq0z2jd.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 1214762466 8536 80.91.229.12 (29 Jun 2008 18:01:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 29 Jun 2008 18:01:06 +0000 (UTC) Cc: emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 29 20:01:51 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 1KD1De-0005NC-Gf for ged-emacs-devel@m.gmane.org; Sun, 29 Jun 2008 20:01:46 +0200 Original-Received: from localhost ([127.0.0.1]:54652 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KD1Co-0001la-Bi for ged-emacs-devel@m.gmane.org; Sun, 29 Jun 2008 14:00:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KD1Cj-0001kJ-8M for emacs-devel@gnu.org; Sun, 29 Jun 2008 14:00:49 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KD1Ci-0001jJ-4n for emacs-devel@gnu.org; Sun, 29 Jun 2008 14:00:48 -0400 Original-Received: from [199.232.76.173] (port=33031 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KD1Ch-0001it-Vq for emacs-devel@gnu.org; Sun, 29 Jun 2008 14:00:48 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:8233) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KD1Ch-0005nx-H7 for emacs-devel@gnu.org; Sun, 29 Jun 2008 14:00:47 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAPdqZ0hFxIdG/2dsb2JhbACBW6xngXo X-IronPort-AV: E=Sophos;i="4.27,723,1204520400"; d="scan'208";a="23741000" Original-Received: from 69-196-135-70.dsl.teksavvy.com (HELO pastel.home) ([69.196.135.70]) by ironport2-out.teksavvy.com with ESMTP; 29 Jun 2008 14:00:46 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id B6D1F835A; Sun, 29 Jun 2008 14:00:46 -0400 (EDT) In-Reply-To: <87prq0z2jd.fsf@stupidchicken.com> (Chong Yidong's message of "Sun, 29 Jun 2008 11:25:26 -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:100146 Archived-At: > Typo. I meant to use the font attribute of the default face in the new > frame: > *** trunk/lisp/faces.el.~1.416.~ 2008-06-28 22:14:35.000000000 -0400 > --- trunk/lisp/faces.el 2008-06-29 11:11:35.000000000 -0400 > *************** > *** 2056,2061 **** > --- 2056,2065 ---- > (make-face-x-resource-internal face frame)) > (internal-merge-in-global-face face frame)) > (error nil))) > + ;; The face specs may specify a different default font. Save this > + ;; in the `font' frame parameter. > + (when (face-font 'default frame) > + (set-frame-parameter frame 'font (face-font 'default frame))) > ;; Apply the attributes specified by frame parameters. This > ;; rewrites parameters changed by make-face-x-resource-internal > (dolist (param apply-params) > The point is that the default face in the new frame specifies a font > (based on its family, slant, and weight attributes) that may differ from > the `font' frame parameter. In that case, it's the former we should > use. The call to face-font returns a font object consistent with the > attributes of the default face. Any font-parameter supplied by the user > further overrides this. Make sense? Yes, it makes a bit more sense, except that now I wonder why this code would be needed at all? Isn't the `font' frame-parameter automatically always kept up-to-date with the font of the `default' face? If not, I think it should, and hence it should be done elsewhere so that it's also true when we later change the default face via `set-face-attributes' or something like that. >> It appears to read some of the settings for the `default' face from >> face-new-frame-defaults and then applies them to the `default' face on >> the current frame. This seems both useless and dubious: >> face-new-frame-defaults is presumably obeyed elsewhere already, and >> why should we only play with the `font' part of the `default' face? > Not sure. It's possible that some of the operations in > face-new-frame-defaults need some information in the default face, > e.g. to figure out column widths, even if that information is later > revised. I do not follow. AFAIK, there are no operations in face-new-frame-defaults, and I have no idea what column width come into play. Can you give a concrete example, maybe? >> - apply defface >> - apply Xresources >> - apply face-new-frame-defaults >> - apply frame-parameters >> >> The first 3 will always return the exact same result for every frame on >> the same terminal (at least, if we ignore frame-specific Xresource >> settings). >> >> So I don't see why we can't just precompute this result at >> terminal-creation time and store it directly in face-new-frame-defaults >> (after making this variable terminal-local). > Now I see your point. > The problem with this proposal is that if Lisp code changes the defface > spec, we would need to update this value by recomputing X resources, > face-new-frame-defaults, etc etc. Since we allow Lisp code to access > defface specs as Lisp lists instead of using accessor functions, I don't > see how to handle this. I don't understand how that's relevant: the same problem exists already today, doesn't it? Stefan