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#46853: Confusing terminology "face height" instead of "font size" Date: Thu, 04 Mar 2021 15:41:34 +0200 Message-ID: <838s73jasx.fsf@gnu.org> References: <875z2a4x2c.fsf@gnus.org> <87tupu3cdd.fsf@gnus.org> <87pn0i3c0j.fsf@gnus.org> <83wnuq7izl.fsf@gnu.org> <874khu3aiw.fsf@gnus.org> <83o8g27hoa.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39825"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46853@debbugs.gnu.org, larsi@gnus.org To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Mar 04 14:43:08 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 1lHoFw-000AGp-Mr for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 04 Mar 2021 14:43:08 +0100 Original-Received: from localhost ([::1]:52816 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHoFv-0001yG-Oz for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 04 Mar 2021 08:43:07 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40738) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHoFq-0001xr-Fw for bug-gnu-emacs@gnu.org; Thu, 04 Mar 2021 08:43:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46589) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lHoFq-00036E-8t for bug-gnu-emacs@gnu.org; Thu, 04 Mar 2021 08:43:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lHoFq-0002r2-73 for bug-gnu-emacs@gnu.org; Thu, 04 Mar 2021 08:43:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Mar 2021 13:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46853 X-GNU-PR-Package: emacs Original-Received: via spool by 46853-submit@debbugs.gnu.org id=B46853.161486532410907 (code B ref 46853); Thu, 04 Mar 2021 13:43:02 +0000 Original-Received: (at 46853) by debbugs.gnu.org; 4 Mar 2021 13:42:04 +0000 Original-Received: from localhost ([127.0.0.1]:58135 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHoEt-0002pr-Oz for submit@debbugs.gnu.org; Thu, 04 Mar 2021 08:42:04 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50740) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHoEp-0002pM-FG for 46853@debbugs.gnu.org; Thu, 04 Mar 2021 08:42:01 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59249) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHoEj-0002Ys-RC; Thu, 04 Mar 2021 08:41:53 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4771 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lHoEj-0002EI-9H; Thu, 04 Mar 2021 08:41:53 -0500 In-Reply-To: (message from Stefan Kangas on Wed, 3 Mar 2021 16:43:07 -0600) 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:201391 Archived-At: > From: Stefan Kangas > Date: Wed, 3 Mar 2021 16:43:07 -0600 > Cc: 46853@debbugs.gnu.org > > > Sorry, no, because that would mislead by catering to the "usual" cases > > and ignoring the rest. What I think we should do instead is talk > > about the default face, and then add a note that other faces will be > > affected if they don't specify :height. > > Yes, this would be an improvement. But I have found it less than > helpful with this talk about the `default' face, since it evidently > scales *all* faces. As this discussion shows, it definitely doesn't scale _all_ of them. > It also maintains the terminological confusion that is the reason for > this bug report -- i.e. it talks about "the default face" instead of > "the font size" [in the current buffer]. There's no such thing as "the font in the current buffer" in modern Emacs, because we are capable of using quite a few fonts in the same buffer. > > So I would propose: > > a) Talking about "changing font size". That is after all the most > striking user visible effect, and it is what normally happens in most > buffers. I didn't object to mentioning the font, I object to mentioning it without _also_ mentioning the face(s) whose font attribute is affected. > b) On row two of the docstring (or three or whatever) we explain the > exact details, something like: > > "This scales all faces that do not have an absolute :height specified. The "absolute" part is inaccurate, see the other mail in this thread. > As an exception, the `default' face is scaled even if it has an > absolute :height. This exception also applies to the `header-line' > face if the variable `text-scale-remap-header-line' is non-nil." > > This seems both more accurate, and less confusing to me. > > I think the difference between the two proposals is that this puts the > technical "implementation details" further down, and the user-visible > effects higher up. (I put "implementation details" in quotes because it > becomes important as soon as you start customizing faces with absolute > values.) Which doc string are you alluding to here? There's IMO a difference between doc strings of user commands and doc strings of the rest of the functions and variables. The latter don't need to cater too much to users, so they can be more rigorous. Doc strings for user commands and options should perhaps start with an easier to understand text, but should afterwards have notes that prevent erroneous interpretation. IOW, we need to consider the doc strings on a case by case basis.