From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#60585: 30.0.50; global-text-scale-adjust shrinks window (was not before), was: Re: bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong Date: Mon, 13 Feb 2023 11:09:05 +0100 Message-ID: References: <80e7f515-e16f-5ce8-86a3-e5f47cd2d2f5@yandex.ru> <67b92c69-f456-0d31-c7b2-83600cc12f61@yandex.ru> <936558fd-5c6e-f575-7211-3d6a14f8febd@yandex.ru> <46994f90-a8ab-7797-73f6-51af01759fb1@gmx.at> <661a804a-ad05-81f8-1aa0-b83811a0576c@yandex.ru> <9c02c0b0-9b96-7d46-37ae-a258a9496891@gmx.at> <3ba27f8c-779a-6f29-45a1-2b7e5a4dcb14@gmx.at> <0144e9a3-57ab-6549-d382-744b141066ec@yandex.ru> <90b5e151-39d1-0248-7be5-8084d8883e5f@gmx.at> <309dcf34-b553-58c2-34a5-270028b05347@yandex.ru> <8913f7e5-5509-3a8e-7413-991b404c3e4e@gmx.at> <4826afb4-e4a7-3845-4cc4-c696123b5e8d@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13564"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 60585@debbugs.gnu.org, rpluim@gmail.com To: Dmitry Gutov , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 13 11:10:16 2023 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 1pRVmp-0003Os-KJ for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 13 Feb 2023 11:10:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pRVmg-0004t1-5B; Mon, 13 Feb 2023 05:10:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pRVmc-0004q9-J1 for bug-gnu-emacs@gnu.org; Mon, 13 Feb 2023 05:10:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pRVmc-0002h2-9l for bug-gnu-emacs@gnu.org; Mon, 13 Feb 2023 05:10:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pRVmb-0001ss-VB for bug-gnu-emacs@gnu.org; Mon, 13 Feb 2023 05:10:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Feb 2023 10:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60585 X-GNU-PR-Package: emacs Original-Received: via spool by 60585-submit@debbugs.gnu.org id=B60585.16762829637186 (code B ref 60585); Mon, 13 Feb 2023 10:10:01 +0000 Original-Received: (at 60585) by debbugs.gnu.org; 13 Feb 2023 10:09:23 +0000 Original-Received: from localhost ([127.0.0.1]:47700 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pRVly-0001rq-Ng for submit@debbugs.gnu.org; Mon, 13 Feb 2023 05:09:23 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:40105) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pRVlw-0001rb-FE for 60585@debbugs.gnu.org; Mon, 13 Feb 2023 05:09:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417; t=1676282954; bh=+tV4OYlhlwFRSMqq3ilaCxDNit8dQNUoS1yT7ezPN7k=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=c2+C/Ak5a59VFxQtOyyO+PrCkDnNU1NZoj4c6WfLQO0xHpf9KNuA/9cJOfSbGqTqu 1ywgmAWjAZEINPICVUeK0ni67JEIe4Oo2MCBhh7Gg2o9uME24RIbvet8HbBIwqjPBF B4lHddn01AFwxgM21qGMFRk+7zEhS7N1aK+/3hjQ9JpSDyVKNS7LvuwkeEzMKiv5vo NiNTLcN4zFX+V7Nal1nVlcpfMSL4vKgIfuOUUVnM/9/3x3Pp1278uitmhVSvO/d8ZA XxXe/Q4CC5sNei8tOLLYZlvFWr3E6uruOgBjg/bUW2icofZfuf4JEYU3K4WguovKqZ G/tC01LVbb6Qw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.1.100] ([213.142.96.201]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MBDj4-1pH5Ns0PS2-00CjGo; Mon, 13 Feb 2023 11:09:14 +0100 Content-Language: en-US In-Reply-To: <4826afb4-e4a7-3845-4cc4-c696123b5e8d@yandex.ru> X-Provags-ID: V03:K1:SZE9ecTwq27EKfEBi502CeVeQp7mueEFXYV2SBGUOWVQQ882QO0 Kg9IQkshuUnS7bNCAmC6W7FJugZUYzxOYP8O8Ujr6wNKkW1NA5Gb/cI6oAvNmXwFFcvPQks qp6ANBoyzSnCd04fvmO7SNZlxxSakW9i0ITsTGrB7NQ5oPBuM8ah3Y/tAsQOWT0s585WnC5 vDoCOLVqNI1v3YPTVQgHw== UI-OutboundReport: notjunk:1;M01:P0:UYvOR+zwWhQ=;3aBs7OZaUxslhV9p7QaC9hqPPkT W6/qoZwyz4IJEqfQ4iOiuZVQOBgqoca5RaiGwGuMLt6N4KfNL1rKqQU/OdX0uMaU2SV0Z3JHA EpaMY+PPSezlGseK+IhkJeawd8UokQJkBnLpWQhGjyKY2Fc7F694XBxKFnbEEWc5GENhGUW10 uw/R5SZANmDQKgJl2fFYLAwQ81+rKCDfDraGH+4RVyyb0F+0VplvrGZ9kxZfryMahF1D8squz Emb51u8wr6e+/zjF3wmcht09uL6q8PW1bXxFsUjQFDSJ+31WKlLeEsAN5WWQ0CzkKtgcMfArb aLtG1x2kJeIgy6oSSSw6lApx0uvUngNZeOVK7m3DD6g+NP+DupjhnkUZH3SsIFCwDRalyxYxU oZTd7+WTlmTqrkalXNmtrAYGv/okX1y0cv93mhMPfz7IO5furflOQrOPxfC5Ux5uaivEQmGD6 5IPsDx5oWO5VfFkWgjkT6zlUPGKtOOUn68Ybf+xq+DVqCjhL+lFx5KnJBu2UAWE5yK0i5sffa lMxWb/2ZQ1NGNzXp4xMaaCsDMh60Fc++9BbwXp0RsW3RJJOuOGFXejWHvqVGlPx6aTwL98OVo urALvW7eq6L5wYnRppcOubDLRO+q2fPFy3xbofohN7EKZ0Fa0Ygaq6ORFDfR8qGTNt/A0udzW PJxhjU+lWi9BZX+xyoAENpfunSH9nQMEhmE8O6wEtYjq9t93AAixhmncUx6LzfpvuWArs8qxA g6OcNF7gFaFPEBKtrhFc6Y0sw4mXEfjN2y+IOzYFTeNm8nwDUgjPGs5hqHI2nbjSY00l45Jt 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:255477 Archived-At: >> > The end of *foo* for GTK3 contains: >> > >> > xg_frame_resized old native pixels 1488x1296 new native pixels 1488x1346 >> > xg_frame_resized old native pixels 1488x1296 new native pixels 1488x1296 >> > xg_wm_set_size_hint scale 2 char width 18 toolbar 0 vscroll 32 fringes 16 borders 0 text width 720 base width 33 width inc 9 >> > char height 36 menubar 50 toolbar 0 hscroll 0 borders 0 text height 648 base height 43 height inc 18 >> > xg_wm_set_size_hint scale 2 char width 18 toolbar 0 vscroll 32 fringes 16 borders 0 text width 720 base width 33 width inc 9 >> > char height 36 menubar 50 toolbar 82 hscroll 0 borders 0 text height 648 base height 84 height inc 18 >> > xg_frame_set_char_size old native pixels 1488x1296 new native pixels 1488x1296 outer pixels 744x714 outer rest 0x0 >> > base_size 33x84 size increments 9x18 WM hint 79x35 >> >> Can you show me the text pixels values? These are the ones we should >> compare. The native values differ because for Lucid the height includes >> the toolbar which we draw ourselves into the rectangle the WM allots to >> us. GTK draws the toolbar into its own area which is outside the native >> rectangle. > > How do I get that numbers? It's what in *foo* should appear after "new text pixels". >> > And for Lucid, it contains: >> > >> > EmacsFrameResize old native pixels 1474x1332 new native pixels 1474x1354 >> > EmacsFrameResize old native pixels 1474x1332 new native pixels 1474x1354 >> > adjust_frame_size old native pixels 1474x1332 new native pixels 1474x1354 old text pixels 1440x1296 new text pixels 1440x1296 old text chars 80x36 new text chars 80x36 >> >> Here I would have liked to see the value for the scroll bar - vscroll. >> I suppose these differ on Lucid and GTK. That's what in *foo* should appear after "vscroll". >> > Lucid's menu bar and tool bar look shorter in height, with less padding. The font size seems to be equal, however. >> >> When you put the two frames side by side, does the text area start lower >> with GTK? Here they start at exactly the same pixel position. I attach >> a screenshot so you can see. > > It does. See the attached screenshots with unpatched builds. I see. BTW, your Lucid scroll bar doesn't seem to have a ruler (or thumb, or whatever you call it) nor the arrows at top and bottom. > I think the above means that x_new_font is called for the second time even in the Lucid build. Anyway, with GNOME and the patch: > > It is hit twice, and both calls seems to have the same backtrace. > > (gdb) xbacktrace > "internal-set-lisp-face-attribute" (0xf09ff218) > "set-face-attribute" (0xffffd8c0) > "progn" (0xffffda70) > "eval" (0xf09ff180) > "elisp--eval-last-sexp" (0xf09ff100) > "eval-last-sexp" (0xffffdc50) > "funcall-interactively" (0xffffdc48) > "call-interactively" (0xf09ff070) > "command-execute" (0xffffdef8) > > and > > (gdb) backtrace > #0 x_new_font (f=0x5555562f8430, font_object=0x5555569e1a45, fontset=-1) at xterm.c:26517 > #1 0x00005555555c4656 in gui_set_font (f=0x5555562f8430, arg=0x5555568fe364, oldval=0x55555622d224) at frame.c:4733 > #2 0x00005555555c1ff9 in gui_set_frame_parameters_1 (f=f@entry=0x5555562f8430, alist=, alist@entry=0x7fffffffd6f3, default_parameter=default_parameter@entry=true) at frame.c:4325 > #3 0x000055555567fea1 in set_font_frame_param (lface=0x5555562f6e45, frame=0x5555562f8435) at xfaces.c:3816 > #4 Finternal_set_lisp_face_attribute (face=0x5940, attr=, value=, frame=) at xfaces.c:3629 > #5 0x000055555567eb38 in Finternal_set_lisp_face_attribute (face=0x5940, attr=0xdb0, value=0x5555568fe544, frame=) at xfaces.c:3092 > ... > > vs > > (gdb) backtrace > #0 x_new_font (f=0x5555562f8430, font_object=0x555556945b6d, fontset=-1) at xterm.c:26517 > #1 0x00005555555c4656 in gui_set_font (f=0x5555562f8430, arg=0x5555563e1e74, oldval=0x5555568fe364) at frame.c:4733 > #2 0x00005555555c1ff9 in gui_set_frame_parameters_1 (f=f@entry=0x5555562f8430, alist=, alist@entry=0x7fffffffd6f3, default_parameter=default_parameter@entry=true) at frame.c:4325 > #3 0x000055555567fea1 in set_font_frame_param (lface=0x5555562f6e45, frame=0x5555562f8435) at xfaces.c:3816 > #4 Finternal_set_lisp_face_attribute (face=0x5940, attr=, value=, frame=) at xfaces.c:3629 > #5 0x000055555567eb38 in Finternal_set_lisp_face_attribute (face=0x5940, attr=0x1020, value=0x1ba, frame=) at xfaces.c:3092 > ... > > What seems to be different between the two are the font_object argument to x_new_font and the arguments to Finternal_set_lisp_face_attribute at the end of the backtrace. > > It seems like they are called twice because my original example sets two attributes: :height and :family. So whenever we do 'set-face-attribute' to set both :height and :family, we do the frame resizing twice, once for the family which apparently assigns a new character size and once for the height. This is bad: Why ask the WM twice to set the frame size in one and the same call? When 'frame-inhibit-implied-resize' is nil, these calls should be collapsed into one and setting the size hint values should be always delayed. >> > Should we try to circle back to finding the difference between >> > "InconsolataLGC" and "Inconsolata LGC"? The latter doesn't exhibit >> > most of the problematic behaviors we have been discussing here. >> >> The first thing to try would be obvious: Does the latter trigger the >> "two x_new_font entries in *foo* in a row behavior"? > > When called for the first time -- yes: > > x_new_font old char size 18x36 new char size 21x45 text chars 80x36 old text pixels 1440x1296 new text pixels 1680x1620 > xg_wm_set_size_hint scale 2 char width 21 toolbar 0 vscroll 32 fringes 16 borders 0 text width 840 base width 34 width inc 10 > char height 45 menubar 50 toolbar 82 hscroll 0 borders 0 text height 810 base height 106 height inc 22 > xg_frame_set_char_size old native pixels 1488x1296 new native pixels 1728x1620 outer pixels 864x876 outer rest 0x0 > base_size 34x106 size increments 10x22 WM hint 83x35 > xg_frame_resized old native pixels 1488x1296 new native pixels 1728x1620 > adjust_frame_size old native pixels 1488x1296 new native pixels 1728x1620 old text pixels 1440x1296 new text pixels 1680x1620 old text chars 80x36 new text chars 80x36 > base_size 34x106 size increments 10x22 WM hint 83x35 > > x_new_font old char size 21x45 new char size 17x37 text chars 80x36 old text pixels 1680x1620 new text pixels 1360x1332 > xg_wm_set_size_hint scale 2 char width 17 toolbar 0 vscroll 32 fringes 16 borders 0 text width 680 base width 32 width inc 8 > char height 37 menubar 50 toolbar 82 hscroll 0 borders 0 text height 666 base height 84 height inc 18 > xg_frame_set_char_size old native pixels 1728x1620 new native pixels 1408x1332 outer pixels 704x732 outer rest 0x0 > base_size 32x84 size increments 8x18 WM hint 84x36 > xg_frame_resized old native pixels 1728x1620 new native pixels 1408x1332 > adjust_frame_size old native pixels 1728x1620 new native pixels 1408x1332 old text pixels 1680x1620 new text pixels 1360x1332 old text chars 80x36 new text chars 80x36 > base_size 32x84 size increments 8x18 WM hint 84x36 > > When called the second time -- no: > > x_new_font old char size 17x37 new char size 17x37 text chars 80x36 old text pixels 1360x1332 new text pixels 1360x1332 > > When called the third time and further -- no entries are added to *foo* at all. OK. But what _is_ the difference between the "InconsolataLGC" and "Inconsolata LGC" calls here? IIUC the "called for the first time" behavior for "InconsolataLGC" is that the second x_new_font call does not happen. Is that right? Please post the respective section of *foo* for that first call so we can compare how it differs from the "Inconsolata LGC" one. To elaborate: The trace you show above resizes the frame twice, apparently once for the :height and once for the :family change. So we should find out why the call for "InconsolataLGC" does not try to resize the frame twice. It should be something like not finding a suitable font with "InconsolataLGC" or at least one that does not ask for changing the height BTW - do we call x_new_font for the :height first here (which would be bad IMO)? >> > Visually, the resulting text seems identical between these two >> > fonts. Maybe the former font name is somehow "autocorrected" into the >> > latter? And that triggers some kind of callback internally that can >> > additionally resize the frame? >> >> Maybe fontset_from_font does such a thing. We'd have to find out first >> whether the values x_new_font finds for font->average_width and >> font_ascent + font_descent differ for the two Inconsolatas. > > Anything I can evaluate to find that out? We had it in *foo* but I removed it because it didn't show anything unexpected. Putting a breakpoint after the line get_font_ascent_descent (font, &font_ascent, &font_descent); in xterm.c should do (it's probably the second hit). Then print the values of font->average_width, font_ascent and font_descent but make sure to do it for both - "InconsolataLGC" and "Inconsolata LGC" - so we can compare them. Thanks, martin