From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov 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: Sun, 29 Jan 2023 03:25:00 +0200 Message-ID: <309dcf34-b553-58c2-34a5-270028b05347@yandex.ru> References: <80e7f515-e16f-5ce8-86a3-e5f47cd2d2f5@yandex.ru> <36f67e04-8450-5273-2136-fb9832ed703f@gmx.at> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25793"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Cc: 60585@debbugs.gnu.org, rpluim@gmail.com To: martin rudalics , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jan 29 02:26:24 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 1pLwSe-0006VJ-C4 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 29 Jan 2023 02:26:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pLwSK-00074V-Bl; Sat, 28 Jan 2023 20:26:04 -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 1pLwSI-000747-U8 for bug-gnu-emacs@gnu.org; Sat, 28 Jan 2023 20:26:02 -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 1pLwSI-000436-BQ for bug-gnu-emacs@gnu.org; Sat, 28 Jan 2023 20:26:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pLwSH-0008Fy-W0 for bug-gnu-emacs@gnu.org; Sat, 28 Jan 2023 20:26:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 Jan 2023 01:26: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.167495551431676 (code B ref 60585); Sun, 29 Jan 2023 01:26:01 +0000 Original-Received: (at 60585) by debbugs.gnu.org; 29 Jan 2023 01:25:14 +0000 Original-Received: from localhost ([127.0.0.1]:41781 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pLwRV-0008Eo-Cr for submit@debbugs.gnu.org; Sat, 28 Jan 2023 20:25:13 -0500 Original-Received: from mail-wm1-f48.google.com ([209.85.128.48]:44916) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pLwRR-0008EW-3I for 60585@debbugs.gnu.org; Sat, 28 Jan 2023 20:25:12 -0500 Original-Received: by mail-wm1-f48.google.com with SMTP id l41-20020a05600c1d2900b003daf986faaeso5938987wms.3 for <60585@debbugs.gnu.org>; Sat, 28 Jan 2023 17:25:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=6jubtraC7ml03fmn7eomhtXk08VJLNrzFSr5o5SoDFI=; b=OaF7hNslP4zJnrrGSGak2TcW7678fwUPL30QPVTwOB/ZvaSVI3pNTlY0ch+wCI6Ej5 +Wbw0ulig2NySJ0QSmAsldzmTngYZJdMOInm8Qk7r362j/9+hDP9EYas3Aq5AjclUoG+ AiAIYMWh+wAw3yViTOTa3mfjeCHWhg2tbbU6U/qSTC6XKE72wsjKtYD+8xB6QSr/sUvX GEg2iQvxI7oMphMXtRcY+JGare9BJ+H2v6phfW7qYCjPM+cckoZTSXhc2WUxrIiM+pMF hNn7iHCbDOD6K0egfEEvjcHF0ulMrx4CUEs3e+EvW7D/5wgBErrievQTXFDclyCUzXtB aS0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6jubtraC7ml03fmn7eomhtXk08VJLNrzFSr5o5SoDFI=; b=Wg2+B9UKlsvjHFHBqOr8fn9J4cTH/nIRt/04TZkStWjOQAZKmVMieu2oYDK0VyJR9R hkY4OQ6+I0yZCigzzn0boSWMUnaJ3i2l+Ph5qTo8fK7Gnd1TWBs2AkuUPgeDLfBl5Jts gNbx0mJo8knLVYexheJmFOKXpasAK7+SyJat6wqhZ3+vSSMQ97eIJK/SLwmH6JwCfUz+ hJHEI9ktHir7AxLPkPwDlSvmAIsRdjs+b8A79sNRriNdejEA3BtJFpDlu6avvK6nSrwJ ynFrImFPvMLQrvFB8zGFmys88DK+kD6gRk7tsJS5sk+mZAMF+nmUertIR72WgOgmvJ7i FGTA== X-Gm-Message-State: AFqh2krD6Bl/V/TYCO8KBqg2RQmj2l8H/KwvzJAphXwpRjSlr7EwCl3m T4b/evC9C3HwAaQIAq90PgU= X-Google-Smtp-Source: AMrXdXtxYXjc6i5r5mYm6r2Q+7qDeK0VgmQ1Z8ViCz9wC2oLJcQNzdPSt7XMmUvL86j5sYHzn1/uHw== X-Received: by 2002:a05:600c:4f45:b0:3cf:68d3:3047 with SMTP id m5-20020a05600c4f4500b003cf68d33047mr44722409wmq.41.1674955503091; Sat, 28 Jan 2023 17:25:03 -0800 (PST) Original-Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id g12-20020a05600c310c00b003db012d49b7sm21156057wmo.2.2023.01.28.17.25.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 28 Jan 2023 17:25:02 -0800 (PST) Content-Language: en-US In-Reply-To: <90b5e151-39d1-0248-7be5-8084d8883e5f@gmx.at> 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:254323 Archived-At: On 28/01/2023 17:36, martin rudalics wrote: > >> This shows how scaling strongly affects whatever GNOME displays here > and > >> what Emacs uses internally.  It might be illustrative to put two > equally > >> sized frames above each other - one from a GTK and one from a Lucid > >> build - and look at what size hints GNOME displays for each of them. > > > > Let me know if you really need that -- I'd have to compile Emacs in > two separate directories. > > One of these days please do.  Eventually we need someone to tell us how > Lucid builds scale and whether the results look different from the GTK > builds.  If nobody knows, we could try to guess from what Lucid and GTK > frames look like on your display. OK, I have done so now. First of all, they start up with different dimensions: Lucid's is a bit shorter and narrower. GNOME says Lucid is 78x34 and GTK3 is 79x35. Internally, both think they are 80x36. 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 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 (I avoid inserting the full contents for brevity, they are several times longer in both cases.) Lucid's menu bar and tool bar look shorter in height, with less padding. The font size seems to be equal, however. And the tool bar icons are scaled on Lucid too. I tried to resize them, but (as long as pixelwise resizing is disabled), they don't match exactly. But if I line them up very close, GNOME says Lucid (which is slightly larger) is 81x37 and GTK3 is 80x36. Here are respective logs: GTK3: xg_frame_resized old native pixels 1506x1296 new native pixels 1488x1296 adjust_frame_size old native pixels 1506x1296 new native pixels 1488x1296 old text pixels 1458x1296 new text pixels 1440x1296 old text chars 81x36 new text chars 80x36 base_size 33x84 size increments 9x18 WM hint 79x35 xg_frame_resized old native pixels 1488x1296 new native pixels 1488x1332 adjust_frame_size old native pixels 1488x1296 new native pixels 1488x1332 old text pixels 1440x1296 new text pixels 1440x1332 old text chars 80x36 new text chars 80x37 base_size 33x84 size increments 9x18 WM hint 79x36 xg_frame_resized old native pixels 1488x1332 new native pixels 1506x1332 adjust_frame_size old native pixels 1488x1332 new native pixels 1506x1332 old text pixels 1440x1332 new text pixels 1458x1332 old text chars 80x37 new text chars 81x37 base_size 33x84 size increments 9x18 WM hint 80x36 Lucid: EmacsFrameResize old native pixels 1492x1354 new native pixels 1492x1390 adjust_frame_size old native pixels 1492x1354 new native pixels 1492x1390 old text pixels 1458x1296 new text pixels 1458x1332 old text chars 81x36 new text chars 81x37 EmacsFrameResize old native pixels 1492x1390 new native pixels 1510x1390 adjust_frame_size old native pixels 1492x1390 new native pixels 1510x1390 old text pixels 1458x1332 new text pixels 1476x1332 old text chars 81x37 new text chars 82x37 EmacsFrameResize old native pixels 1510x1390 new native pixels 1510x1426 adjust_frame_size old native pixels 1510x1390 new native pixels 1510x1426 old text pixels 1476x1332 new text pixels 1476x1368 old text chars 82x37 new text chars 82x38 Which is to say Lucid's log is slightly inaccurate here because, again, GNOME reports that window to be 81x37. > >> For the rest, the transcript nowhere shows that the GNOME hints jump by > >> two or more after 'set-face-attribute'.  Can you spot such behavior? > > > > The jumps in the log look smooth, but one set-face-attribute > > evaluation creates several log entries. After I resize the frame to > > 118x35 and evaluate the s-f-a form, all of this is printed in the log: > > > > x_new_font old char size 17x37 new char size 17x37 text chars 112x35 > old text pixels 1904x1296 new text pixels 1904x1295 > > xg_wm_set_size_hint scale 2 char width 17 toolbar 0 vscroll 32 > fringes 16 borders 0 text width 952 base width 32 width inc 8 > >      char height 37 menubar 50 toolbar 82 hscroll 0 borders 0 text > height 647 base height 101 height inc 18 > > xg_frame_set_char_size old native pixels 1952x1296 new native pixels > 1952x1295 outer pixels 976x713 outer rest 0x0 > >      base_size 32x101 size increments 8x18 WM hint 118x34 > > xg_frame_resized old native pixels 1952x1296 new native pixels 1952x1294 > > adjust_frame_size old native pixels 1952x1296 new native pixels > 1952x1294 old text pixels 1904x1296 new text pixels 1904x1294 old text > chars 112x35 new text chars 112x34 > >      base_size 32x101 size increments 8x18 WM hint 118x34 > > > > x_new_font old char size 17x37 new char size 17x37 text chars 112x34 > old text pixels 1904x1294 new text pixels 1904x1258 > > xg_frame_set_char_size old native pixels 1952x1294 new native pixels > 1952x1258 outer pixels 976x695 outer rest 0x0 > >      base_size 32x101 size increments 8x18 WM hint 118x33 > > xg_frame_resized old native pixels 1952x1294 new native pixels 1952x1258 > > adjust_frame_size old native pixels 1952x1294 new native pixels > 1952x1258 old text pixels 1904x1294 new text pixels 1904x1258 old text > chars 112x34 new text chars 112x34 > >      base_size 32x101 size increments 8x18 WM hint 118x33 > > > > ...and the frame is 118x33 at the end, naturally. > > This means that if you are sure that you have called it once only, > 'set-face-attribute' manages to run set_new_font_hook twice.  Which > would be a real pain.  Maybe someone has an idea.  Otherwise I have to > invent a counter, increment it in 'set-face-attribute', print it in > x_new_font, have you test it again ... I'm pretty sure, yes. I performed that experiment and observed the log several times. Would a counter really help? I guess you'll be able to confirm what I'm saying, but then what? Would that bring any new information? 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. And when s-f-a is evaluated at dimensions 118x35 with the latter family name, it first corrects the dimensions slightly to 118x34 (with like a few pixel difference in height, 2 or 3), and then no subsequent evaluations of s-f-a change frame dimensions, no matter how I resize it with a mouse first. 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?