all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Gregory Heytings <gregory@heytings.org>
Cc: 60585@debbugs.gnu.org, Jean Louis <bugs@gnu.support>
Subject: bug#60585: 30.0.50; global-text-scale-adjust shrinks window (was not before)
Date: Mon, 9 Jan 2023 11:09:02 +0100	[thread overview]
Message-ID: <ea8ca4c9-cebc-ea1d-c6f0-34634ebbdd47@gmx.at> (raw)
In-Reply-To: <3f4b5c597227e1c31900@heytings.org>

 > I did not reply in the other thread, but it's not
 > global-text-scale-adjust that resizes the frames, it's the window
 > manager (IceWM).  I tried a few other window managers, and they do not
 > resize the frame in such circumstances.

It must be 'global-text-scale-adjust' that (maybe implicitly) asks to
resize the frame.  A WM cannot deliberately resize a frame unless we ask
it to do so.

 > This resizing can be avoided in at least two ways: disabling the
 > scroll bar, and setting frame-resize-pixelwise to t.

Both clearly hint at a problem with our settings of size hints.

 > I'm not 100% sure that the bug I see here is exactly the same as the
 > one Jean sees (he said it's a recent bug, and I can reproduce it even
 > with an Emacs from 2017), but here is the output of a patched Emacs
 > running under IceWM on my system.

Thanks.  These show the problem.  For example, here

x_new_font old char size 13x25 new char size 12x24 text chars 93x27 old text pixels 1209x675 new text pixels 1116x648
adjust_frame_size old native pixels 1243x730 new native pixels 1243x730 old text pixels 1209x675 new text pixels 1209x675 old text chars 93x27 new text chars 100x28

we have

(= (* 93 13) 1209)
(= (* 27 25) 675)

but obviously not

(= (* 100 12) 1209)
(= (* 28 24) 675)

So while we do not explicitly ask for resizing the frame, we apparently
do set the size hints (strictly spoken correctly so, since future mouse
operations should know about them) but do not want to resize the frame.
The first question now is how we arrive here

EmacsFrameResize old native pixels 1243x730 new native pixels 1243x730
update_wm_hints char width 12 vscroll 16 fringes 16 borders 2 base width 46 min width 46
     char height 24 menubar 38 hscroll 0 borders 2 base height 117 min height 117

so please try to find out why x_new_font triggers a setting of the size
hints despite the fact that we do not want to resize the frame (the two
entry points are update_wm_hints in widget.c and x_wm_set_size_hint in
xterm.c).  Maybe we can avoid them - with GTK we apparently do.

But ultimately this is a dilemma for which I have no solution.  I think
that setting the size of the default font is simply the wrong thing to
do here.  We should use some other font hat does not get passed through
to the size hints.

martin





  reply	other threads:[~2023-01-09 10:09 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-05 22:28 bug#60585: 30.0.50; global-text-scale-adjust shrinks window (was not before) Jean Louis
2023-01-06  6:50 ` Eli Zaretskii
2023-01-06  8:17   ` Gregory Heytings
2023-01-06  8:41     ` Gregory Heytings
2023-01-06 13:01       ` Jean Louis
2023-01-06 13:26         ` Gregory Heytings
2023-01-06 14:03           ` Gregory Heytings
2023-01-06 15:16             ` Gregory Heytings
2023-01-06 16:32             ` Jean Louis
2023-01-06 22:05               ` Gregory Heytings
2023-01-06 22:24                 ` Jean Louis
2023-01-07  2:05                   ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-07 17:24                     ` Jean Louis
2023-01-06 22:25                 ` Jean Louis
2023-01-06 22:35                   ` Gregory Heytings
2023-01-07  9:36                     ` Gregory Heytings
2023-01-08  0:38                       ` Jean Louis
2023-01-08 21:41                         ` Gregory Heytings
2023-01-06 14:05           ` Eli Zaretskii
2023-01-06 22:21             ` Jean Louis
2023-01-06 16:35           ` Jean Louis
2023-01-06 12:57     ` Jean Louis
2023-01-06 12:55   ` Jean Louis
2023-01-06 13:18     ` Eli Zaretskii
2023-01-06 16:27       ` Jean Louis
2023-01-06 16:50         ` Eli Zaretskii
2023-01-08 17:42 ` martin rudalics
2023-01-08 21:37   ` Jean Louis
2023-01-09 10:07     ` martin rudalics
2023-01-08 22:14   ` Gregory Heytings
2023-01-09 10:09     ` martin rudalics [this message]
2023-01-09 18:00       ` martin rudalics
2023-01-09 12:44     ` Jean Louis
2023-01-13  6:35   ` Jean Louis
2023-01-13  6:43   ` Jean Louis
2023-01-13  8:38     ` martin rudalics
2023-01-13 17:38       ` Jean Louis
2023-01-14 10:24         ` martin rudalics

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ea8ca4c9-cebc-ea1d-c6f0-34634ebbdd47@gmx.at \
    --to=rudalics@gmx.at \
    --cc=60585@debbugs.gnu.org \
    --cc=bugs@gnu.support \
    --cc=gregory@heytings.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.