bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#60585: 30.0.50; global-text-scale-adjust shrinks window (was not bef


From: martin rudalics
Subject: bug#60585: 30.0.50; global-text-scale-adjust shrinks window (was not before)
Date: Mon, 9 Jan 2023 11:09:02 +0100

> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]