From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#51465: [External] : Re: bug#51465: 27.2; `face-all-attributes' doc or behavior (?) Date: Fri, 29 Oct 2021 10:24:06 +0300 Message-ID: <83y26cqoo9.fsf@gnu.org> References: <83h7d1rlk6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24869"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 51465-done@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Oct 29 09:32:00 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mgMMo-0006Fw-Ps for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 29 Oct 2021 09:31:59 +0200 Original-Received: from localhost ([::1]:34934 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mgMMm-0002GW-0O for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 29 Oct 2021 03:31:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37924) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mgMG6-0002cb-SF for bug-gnu-emacs@gnu.org; Fri, 29 Oct 2021 03:25:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42391) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mgMG6-0006zr-GP for bug-gnu-emacs@gnu.org; Fri, 29 Oct 2021 03:25:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mgMG6-0003VD-9y for bug-gnu-emacs@gnu.org; Fri, 29 Oct 2021 03:25:02 -0400 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Fri, 29 Oct 2021 07:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 51465 X-GNU-PR-Package: emacs Mail-Followup-To: 51465@debbugs.gnu.org, eliz@gnu.org, drew.adams@oracle.com Original-Received: via spool by 51465-done@debbugs.gnu.org id=D51465.163549227113416 (code D ref 51465); Fri, 29 Oct 2021 07:25:02 +0000 Original-Received: (at 51465-done) by debbugs.gnu.org; 29 Oct 2021 07:24:31 +0000 Original-Received: from localhost ([127.0.0.1]:53936 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mgMFa-0003UK-OL for submit@debbugs.gnu.org; Fri, 29 Oct 2021 03:24:31 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40104) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mgMFY-0003U6-3Y for 51465-done@debbugs.gnu.org; Fri, 29 Oct 2021 03:24:29 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57408) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mgMFS-0006p3-RP; Fri, 29 Oct 2021 03:24:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=vjEulf5r7WcexBfGW4Sgjje8pqmD2Vmfy+g4vtk8gGE=; b=ZeqcY2nkQ/BTxKPWhNA3 fpU6Xp5x7XHEDV5wGrR39tGqmw+2AOr6ZE24gGmRfzC8P9VkV442NUzRZyimXlZ9l97F7ZubJMd59 PDxfeWGuiHF0j66nDFcLS5bzqU6W1E7qyyyNQeOw4ksPykGGimf1WTDZMwqxVHX6Q/mJmJ9RfZOuk kQNdHPJ8N8PV3mm38dX6ZbAggWZj0uwnBenqPoTJbFyFbkxOjzJhXHsVupp3l1PbyNa1GPc9r2K5w fYuPEwL7IbS1o0DmfI0W+YU9GAM07J57J/3fHCeLXCe6As+pvx3thLBm6AiE+0wavdvojJbQca+6d tvCeLEeDLKwqNg==; Original-Received: from [87.69.77.57] (port=4180 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mgMFS-0002W9-C8; Fri, 29 Oct 2021 03:24:22 -0400 In-Reply-To: (message from Drew Adams on Thu, 28 Oct 2021 23:08:42 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:218536 Archived-At: > From: Drew Adams > CC: "51465@debbugs.gnu.org" <51465@debbugs.gnu.org> > Date: Thu, 28 Oct 2021 23:08:42 +0000 > > > > (elisp) `Attribute Functions' says "the default attributes of FACE > > > for newly created frames". I would expect to see :background as > > > "LightGoldenrod", not as `unspecified'. > > > > Why? because that's what you actually see in a new frame? Those > > aren't the default attributes, those are the attributes specified by > > defface. > > The Elisp manual says it returns "the default attributes > of FACE for newly created frames." > > Whenever I create a new frame (from emacs -Q) that face > on that frame has a :background of "LightGoldenrod" - > never `unspecified'. Is the manual wrong? No, it isn't wrong: the "default attributes for newly created frames" are those the face has before applying the definitions in defface. Note that the description of face-attribute in the same section already hints on what is going on here: If FRAME is ‘t’, this function returns the value of the specified attribute for newly-created frames (this is normally ‘unspecified’, unless you have specified some value using ‘set-face-attribute’; see below). If you use set-face-attribute with the FRAME argument t to set some attribute's value, the next call to face-all-attributes will no longer show 'unspecified' for that attribute. And the next frame created after that will use the attribute value you specified, effectively overriding the corresponding attribute's value defined by defface. > Unless otherwise specified (which could be by > `default-frame-alist' or whatever) a newly created > frame has, according to the manual, the attributes > for that face that are given by `face-all-attributes' > when that function is passed a nil FRAME arg: "the > default attributes of FACE for newly created frames." > > IOW, it calls this "the default attributes" for > "newly created frames", not the attributes for some > existing frame (this is the FRAME=nil case). > > And yet, with emacs -Q, every newly created frame > has :background set to "LightGoldenrod" (AFAICT). > At the very least, most, if not all, newly created > frames have that attribute value. None have that > attribute with a value of `unspecified'. That's because defface's definitions are merged with those defaults, when the frame is created, which in this case yields the non-unspecified background color. So you rarely if ever see those default attributes, except if you call this function. > I'd think that "default" would just mean what you > get for a newly created frame unless there is > something that overrides that somehow. That is correct, and that is what happens here; see above. > I'd think that "default" is what the current customized value of the > face has - that's what you get by default for a newly created frame > (or if it's not customized then the value given by the original > defface). Right. But the default values are before merging the defface's definitions. > I'm hoping you at least see a possibility for > confusion in the doc. Thanks, I've now clarified the documentation on the release branch to be more specific about the meaning of "default" in this context, and made sure the same explanation appears in both face-attribute and face-all-attributes. > And maybe even a problematic behavior I see no problems in the behavior, no. It's just a complex issue, and it isn't easy to explain it clearly to readers that aren't necessarily privy to the implementation details. Hopefully, it's more clear now. > (what's the point of returning `unspecified' everywhere?). Only if no default values were defined via set-face-attribute. And with that, I'm closing this bug report.