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#17532: 24.4.50; Options > `set-frame-font' does not work as documented Date: Wed, 21 May 2014 11:03:44 -0700 (PDT) Message-ID: References: <<7f75d016-b170-4502-999a-ab657354e6b2@default>> <<8361kznkpy.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1400695473 11328 80.91.229.3 (21 May 2014 18:04:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 21 May 2014 18:04:33 +0000 (UTC) Cc: 17532@debbugs.gnu.org To: Eli Zaretskii , Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed May 21 20:04:26 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WnAsJ-0007kq-DA for geb-bug-gnu-emacs@m.gmane.org; Wed, 21 May 2014 20:04:23 +0200 Original-Received: from localhost ([::1]:33016 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WnAsI-0002ML-Nr for geb-bug-gnu-emacs@m.gmane.org; Wed, 21 May 2014 14:04:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49412) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WnAs7-0002Lq-A0 for bug-gnu-emacs@gnu.org; Wed, 21 May 2014 14:04:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WnAry-0002NU-I7 for bug-gnu-emacs@gnu.org; Wed, 21 May 2014 14:04:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56694) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WnAry-0002NH-Eq for bug-gnu-emacs@gnu.org; Wed, 21 May 2014 14:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WnArx-0005yP-KA for bug-gnu-emacs@gnu.org; Wed, 21 May 2014 14:04:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 21 May 2014 18:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17532 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17532-submit@debbugs.gnu.org id=B17532.140069543922952 (code B ref 17532); Wed, 21 May 2014 18:04:01 +0000 Original-Received: (at 17532) by debbugs.gnu.org; 21 May 2014 18:03:59 +0000 Original-Received: from localhost ([127.0.0.1]:55571 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WnAru-0005y8-Iz for submit@debbugs.gnu.org; Wed, 21 May 2014 14:03:59 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:36132) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WnArr-0005xs-0V for 17532@debbugs.gnu.org; Wed, 21 May 2014 14:03:56 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4LI3lRP011364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 May 2014 18:03:48 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4LI3jig014831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 May 2014 18:03:45 GMT Original-Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4LI3i54013300; Wed, 21 May 2014 18:03:44 GMT In-Reply-To: <<8361kznkpy.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.5000 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 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.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:89332 Archived-At: > > > But that doesn't cover future frames, either. It only affects the > > > existing GUI frames, per the doc string (and the code, which see). > > ^^^^^^^^^^^^^^^^^^ > > > > Where are you getting this? `C-h f set-frame-font' says clearly: > > > > Also, if FRAME is non-nil, alter the user's Customization settings a= s > > though the font-related attributes of the `default' face had been > > "set in this session", so that the font is applied to future frames. > > > > One of us seems to be sorely missing something. ;-) >=20 > You are missing the previous sentence of the doc string. No, I was not missing that previous sentence:=20 "If FRAMES is non-nil, it should be a list of frames to act upon, or t meaning all graphical frames." Where does it say that only existing frames should be affected? It says that `t' means that it affects all graphical frames. Nothing limits that to the existing ones. "All men are created equal" does not refer only to the men that existed at the time that sentence was coined. > I have now made it say clearly that only the existing frames are > affected. Too bad. Anyway I give up. > > A face, including face `default', is not something that is frame-specif= ic. >=20 > Faces are _always_ frame-specific in Emacs. That includes the > 'default' face. Thus, changing the 'default' face does not imply the > change affects all frames, let alone future frames. That's not my understanding. And if that were the case then it would be reflected in the doc. Node (emacs) `Faces' tells you what a face is,=20 and it says NOTHING about it being frame-dependent. Likewise node `Face At= tributes', which tells you what a face is in detail, says nothing about a face definition being frame-dependent. Likewise node `Defining Faces'. And in functions etc. Function `facep' would then require a second arg FRAME or would implicitly tell you only that the object was a face for, say, the selected frame. =20 And customizing a face (including `default') would affect only a particular frame. And `defface' would provide for specifying the frame(s) to which that particular face applies. A face is defined independently of any place it might be displayed, including any frame. A face _attribute_ can have different values for a given face on different frames. That does not mean that the face itself is different. And this overriding of a face's default attribute values is just that: exceptional. As the doc says: Normally, Emacs uses the face specs of each face to automatically calculate its attributes on each frame (*note Defining Faces::). The function `set-face-attribute' can override this calculation by directly assigning attributes to a face, either on a specific frame or for all frames. This function is mostly intended for internal usage. A face's default attributes are what apply to newly created frames. Changing the default font of a face, in particular, should affect new frames. And particularly for face `default'. What's more, the doc says clearly that a `t' value for `set-face-attribute' parameter FRAME " sets the attributes for all existing frames, as well as for newly created frames." Existing and new go together here, and the same doc says clearly that they go together the same way for all of the related `set-face-*' functions - including `set-face-font': The following commands and functions mostly provide compatibility with old versions of Emacs. They work by calling `set-face-attribute'. Values of `t' and `nil' for their FRAME argument are handled just like ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `set-face-attribute' and `face-attribute'. The commands read their ^^^^^^^^^^^^^^^^^^^^ arguments using the minibuffer, if called interactively. Why you would think that `set-face-font' should not do like this doc says and should be an exception to the rule that `t' affects newly created frames as well as existing frames, is beyond me. And even all of the functions that examine face attributes act similarly. In fact, it is ONLY the new-frame behavior of `t' that is kept in this case. The (same) doc says: The following functions examine the attributes of a face. They mostly provide compatibility with old versions of Emacs. If you don't specify FRAME, they refer to the selected frame; `t' refers to the ^^^^^^^^^^^^^^^^^ default data for new frames. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ And yes, this includes function `face-font': FRAME =3D `t' means the default value, which is what affects new frames. > The very next bullet is about a different method of changing the font, > so it's not really relevant to what this first bullet describes. A different method of doing the same thing: changing the font for new frames! ALL of the bullets here describe ways of doing that. > Anyway, I made the changes that clarify the current behavior. The > part that seems to say that Customize settings are changed to affect > the font change on all future frames does not correspond to what > actually happens. This could be a code bug or a documentation bug; > someone who can decipher the Customize-related code in set-frame-font > will have to look into this, and fix either the doc string or the code > as appropriate. For now, I left that part of the doc string > unaltered. Anyway, I give up. I did my part in filing the bug and in trying to explain what I think the bug is: the doc is pretty much right in suggesting that new frames are also affected; the product is wrong in not respecting that.