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) Date: Sat, 14 Jan 2023 11:24:35 +0100 Message-ID: <8cf94d68-e4dc-081f-8ee0-9b817b135000@gmx.at> References: <86mt6wk45n.fsf@protected.rcdrun.com> 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="9680"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 60585@debbugs.gnu.org To: Jean Louis Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jan 14 11:26:29 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 1pGdk4-0002JI-0t for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 14 Jan 2023 11:26:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pGdjk-0005aF-2I; Sat, 14 Jan 2023 05:26:08 -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 1pGdje-0005a1-Hg for bug-gnu-emacs@gnu.org; Sat, 14 Jan 2023 05:26:04 -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 1pGdje-0003Oa-9g for bug-gnu-emacs@gnu.org; Sat, 14 Jan 2023 05:26:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pGdjd-000744-SX for bug-gnu-emacs@gnu.org; Sat, 14 Jan 2023 05:26: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: Sat, 14 Jan 2023 10: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.167369192027106 (code B ref 60585); Sat, 14 Jan 2023 10:26:01 +0000 Original-Received: (at 60585) by debbugs.gnu.org; 14 Jan 2023 10:25:20 +0000 Original-Received: from localhost ([127.0.0.1]:53433 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pGdix-000737-L9 for submit@debbugs.gnu.org; Sat, 14 Jan 2023 05:25:20 -0500 Original-Received: from mout.gmx.net ([212.227.15.15]:41207) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pGdiu-00072o-HN for 60585@debbugs.gnu.org; Sat, 14 Jan 2023 05:25:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417; t=1673691878; bh=8j6Ky3pLOPgpnYigYhoyNF440CiEPwQHgNNUW+LRYc0=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=pb+FCwQCs5CZC9yzMqnagfUF5OwxPPx6GCOd4b9tHKkuLNfOKNgcZr4yN3kAT6Jfp z/wYdRZVyF+J5Rzc85YeYx4bw3hJKE4CjF+wPY1Mf6v/bwzhvvg/WDeXLW+qqkoSMb 9ycw/6WkmZnS6nsjepLHEmgfQZDjbeesnR985nzREswPkLYVPXiOtUD/1/wf1QYpbc d13my7mpA+I/SKL6d8D1ZflpEm2UfeFw7pLv7IHjClZ7jvGLTfvedR8rWL9k2wte1B 5JSxRWRZ8UBfyoV1rno7q6pR7RLVxX42AthAkpbsu+0mJfUz79Y14iIdZZOBFKSBdV bTaqh0c98KYOA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.1.101] ([46.125.249.73]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MyKDe-1oXVFa32aq-00ylTD; Sat, 14 Jan 2023 11:24:38 +0100 Content-Language: en-US In-Reply-To: X-Provags-ID: V03:K1:dhxi9uANVhfhyW1xBayF8zMKSUVuTn82VfKwN5+8JBPnW1vjafR mWWU/gYNdEnoIp3oOfF4Rq/O0bC3rvbjHluv4saup6Q7uUgMSWDpBBniOVnimYVG0nEtxER m3y4IzQSd9r5rhcH4HdDT73TuF411PPj9Ii4unb6DiZo466IQ21ifD08uoi2pnRoL/i47m7 SwRERzgQsJpPAfEUAov9g== UI-OutboundReport: notjunk:1;M01:P0:q/83BsBtA1A=;88ZbP4xsJH+b2GJmzQDIGOnqPU3 7m63+dhqvUNn8NTKenYzm93Rh02T+kebWOI8qV2MUj0/N/Sv4jKRZ5B487QD+220WvpVi3a6W pBwRs5yG8NthKaT1eN+rmVlTmFemGOARwOKGTt91Sn8fdUvrXWtLJxpfN9cl/r8f9KdAvhlN0 dwCS9bz40qfqfNqDoweQowaZTZePMY4ZFUSUzRgcROjRaNLS82GJ1kMkstvinrhIam3SGDLNn cZM/USwaOQnsHsiqXsVxidC88JF85nrOpz5Dt88TtXeQn5GdvPwGUBg7zwzI0A/1A92vO7IfC pBdQV/amxtRpDkN8THiOyGj99yzUmmZzomoYJZhmT6vy131YN19L6MyDP+6h8PGT0asYW6fgM R5coXa2PGDcEBtlI3GmZCQ7ZvIdTFdyvd75oLbBKd+SqWOk4wjAllqplmUqF9GbIOE3F92pZS 6OJm/lfRv82Rh3wUdpYX8KyoZx3d57IooAcnaDW2GfD/WngSpyJmjWObJqtCKwJ1QEELMVFFb IYWf507T2I09BZyMqpeKJA7oW9a6fwpvGHHaiwHm6YyV3nAfdZKKoQPWZnG3v/QTdyX9LB30i gzDfBtxWhJK8/rXN70Ll9kghoD9pwA33y1ZDyr3txFNSgS9ZYTqvXEyC8CYdB9yUfwGZVi5YU nT/rHVAT8JxQ3jbfdIn5/1Is85/dmWyHS3LTKjGL5yrQsmHce2affeazts71874w/LMdwwLQK 0n7SXXMjzbUREPSycd8CuBGubOJjNHYxiKBdFJ8jDvso8a9jihFHgcfmXBn//FPRH4fGkSMw 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:253347 Archived-At: > I missed your instructions, then I pulled new Emacs, did the patch, > and now I can't see shrinking of window in Lucid build. Thank you. This looks better than I expected. > Did anything change in meantime? No. If this was the first time you applied a patch, something might have easily gone wrong. Don't worry. > adjust_frame_size old native pixels 80x25 new native pixels 80x25 old text pixels 80x25 new text pixels 80x24 old text chars 80x25 new text chars 80x24 > adjust_frame_size old native pixels 80x25 new native pixels 818x552 old text pixels 80x25 new text pixels 800x550 old text chars 80x25 new text chars 80x25 > adjust_frame_size old native pixels 818x552 new native pixels 818x574 old text pixels 800x550 new text pixels 800x550 old text chars 80x25 new text chars 80x25 > adjust_frame_size old native pixels 818x574 new native pixels 818x828 old text pixels 800x550 new text pixels 800x792 old text chars 80x25 new text chars 80x36 > update_from_various_frame_slots native pixels 818x828 > set_frame_size native pixels 818x828 > update_wm_hints char width 10 vscroll 0 fringes 16 borders 2 base width 28 min width 28 > char height 22 menubar 0 hscroll 0 borders 2 base height 58 min height 58 > EmacsFrameResize old native pixels 818x828 new native pixels 818x828 > update_wm_hints char width 10 vscroll 0 fringes 16 borders 2 base width 28 min width 28 > char height 22 menubar 0 hscroll 0 borders 2 base height 58 min height 58 > adjust_frame_size old native pixels 818x828 new native pixels 834x828 old text pixels 800x792 new text pixels 800x792 old text chars 80x36 new text chars 80x36 Note the "new text chars 80x36" at the end of the last line. This should appear in any run on a graphic display. It means that we were able to set up the initial frame size as we intended. Earlier on this line you will notice that the native width of the frame increased from 818 to 834 pixels. The 16 pixels stem from the fringes, the vertical scroll bar has not been counted yet. > EmacsFrameResize old native pixels 834x828 new native pixels 818x795 Here we apparently try to account for the scroll bar width (the 16 pixels from 834 to 828) and the tool bar (33 pixels from 828 to 795). The widget builds apparently have to detract these values from the native rectangle to keep the number of lines and columns constant. I never understood the widget code. > update_wm_hints char width 10 vscroll 16 fringes 16 borders 2 base width 48 min width 48 > char height 22 menubar 33 hscroll 0 borders 2 base height 102 min height 102 I elided many identical update_wm_hints lines here. Something's wrong, presumably with that memcmp call in update_wm_hints. > adjust_frame_size old native pixels 834x828 new native pixels 834x830 old text pixels 800x792 new text pixels 800x792 old text chars 80x36 new text chars 80x36 Whatever the code did, we have the expected (* 80 10) 800 and (* 22 36) 792 integral text pixels here. Now things get interesting. > x_new_font old char size 10x22 new char size 11x23 text chars 80x36 old text pixels 800x792 new text pixels 880x828 Here you ask (presumably via 'global-text-scale-adjust') to increase the character size of the default font from 10x22 to 11x23 pixels. This means that if we want to keep the frame's pixel size constant, we have to shrink its text character width (apparently from 80 to 72) and its text character height (from 36 to 34). > adjust_frame_size old native pixels 834x830 new native pixels 834x830 old text pixels 800x792 new text pixels 800x792 old text chars 80x36 new text chars 72x34 Here you can see that both, native and text size in pixels remain unaltered which is what we wanted to achieve. And note that here neither (* 72 11) equals 800 nor does (* 34 23) equal 792. So the text sizes in pixels are no more integral multiples of the sizes in terms of characters. I still think that 'global-text-scale-adjust' should not modify the default font but maybe this ship has sailed. And I suppose that with WMs like yours this problem might bite us in other occasions as well. > EmacsFrameResize old native pixels 834x830 new native pixels 834x830 > update_wm_hints char width 11 vscroll 16 fringes 16 borders 2 base width 53 min width 53 > char height 23 menubar 33 hscroll 0 borders 2 base height 104 min height 104 And here you can see that both the base width and the base height changed - something our code never did before. > x_new_font old char size 11x23 new char size 10x22 text chars 72x34 old text pixels 800x792 new text pixels 720x748 Here, IIUC you size back to the initial size ... > adjust_frame_size old native pixels 834x830 new native pixels 834x830 old text pixels 800x792 new text pixels 800x792 old text chars 72x34 new text chars 80x36 ... and while Emacs restores to our initial 80x36 text chars sizes and keeps the pixel sizes constant ... > EmacsFrameResize old native pixels 834x830 new native pixels 834x830 > update_wm_hints char width 10 vscroll 16 fringes 16 borders 2 base width 44 min width 44 > char height 22 menubar 33 hscroll 0 borders 2 base height 93 min height 93 ... the base size hints go somewhere else (from 48x102 to 44x93) which apparently doesn't harm. For the rest of the experiment note that if things don't go wrong, in each line headed by adjust_frame_size like > adjust_frame_size old native pixels 834x830 new native pixels 834x830 old text pixels 800x792 new text pixels 800x792 old text chars 80x36 new text chars 80x37 both old and next text and native pixels should have the same value after each 'global-text-scale-adjust' call which means that the frame size did not change visually. I invite you to conduct this experiment further and also intersperse manual frame resizes (using the mouse) in between. The idea is that no unexpected or strange resizing should happen any more. Good luck, martin