GNU bug report logs - #60585
30.0.50; global-text-scale-adjust shrinks window (was not before)

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 60585 <at> debbugs.gnu.org, rpluim <at> gmail.com
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: Sat, 21 Jan 2023 05:12:10 +0200

On 18/01/2023 19:13, martin rudalics wrote:
>  > This time around, the frame jumps in size a little bit, even time
>                                                            _every_ right?
> 
>  > after I first resize with a mouse and then evaluate the
>  > set-face-attribute form.
> 
> I'm not sure what to do here.  As we previously discussed, you contract
> an off-by-one pixel error every time you resize the frame with the mouse
> and the default font has impair size.  That pixel is lost in the frame
> size the WM allots us.  So after N mouse operations we are usually off
> by N pixels unless N equals the size of the font in which case the
> deviation should be compensated by our calculation of the text size in
> chars.

The previous scenarios (with one of the patches from the other bug 
thread) had frame at "impair" size only after some resizings with the 
mouse. For most sizes the frame ended up at "correct" sizes, but there 
were relatively rare sizes where this was not the case.

With your last patch here, however, the frame seemingly ended up at an 
"impair" size every time I resized it with the mouse.

> So the size adjustments you see in the latest two patches are inherently
> correct - they restore the text pixel size of the frame as the product
> of the character and font sizes.
> 
> We could try to make 'set-face-attribute' adjust the pixel size of a
> frame iff this would also change the size in text characters.  Hiding
> the rest in the base sizes would allow such behavior now.  But how would
> we explain such behavior to the user?  Also such a beast is non-trivial
> to implement - I have no idea what else it could break.  Try the
> attached and let's hope that it won't blow up your frame.

With this patch 'emacs -Q' starts up at 32x6 columns/lines. :-)

Very small window, that.

Otherwise, the behavior seems pretty stable:

- Repeated invocations of set-face-attribute don't change frame size,
- After resizing with the mouse, at some frame sizes set-face-attribute 
does cause one resize (e.g. at 80x30, according to GNOME), but most do 
not -- just like the older patch I referred to in the first paragraph.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.