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

Previous Next

Full log

Message #149 received at 60585 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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, 22 Jan 2023 03:56:10 +0200

[Message part 1 (text/plain, inline)]

On 21/01/2023 12:08, martin rudalics wrote:
>  > 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.
> 
> For reference let's try to stick to the last x_scale_font.diff patch I
> sent you.  What was the "impair" size there?

According to https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52493#332, 
some impair sizes were 80x36 minus 1 in any dimension using the mouse.

> Note in all theses cases:
> The real size of a frame as it is displayed (or better cut off) by the
> WM is only reflected in our pixel sizes.  The character sizes (including
> those displayed by GNOME) are just approximations which reflect the
> displayed sizes faithfully iff when multiplied by the character sizes
> they result in the corresponding pixel size.

Sure.

>  > With your last patch here, however, the frame seemingly ended up at 
> an "impair" size every time I resized it with the mouse.
> 
> The present one or the one I sent you before?

The one from the message in this thread which I was responding to. File 
called x_rest.diff.

>  > With this patch 'emacs -Q' starts up at 32x6 columns/lines. :-)
>  >
>  > Very small window, that.
> 
> "The Incredible Shrinking Frame"
> 
>  > 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.
> 
> Please send me the *foo* transcript.

Sorry, forgot about it last time. So, with x_rest.diff, the attached 
transcript is of:

1. Resizing the frame to 80x36 (according to GNOME).
2. Evaluating the set-face-attribute form twice.
3. Resizing the frame to 80x20 (per GNOME), which is 76x20 according to 
our internal measurements.
4. Evaluating the set-face-attribute form twice again.
5. Resizing to 80x32.
6. Evaluating s-f-a twice again.

In this scenario, step 4 doesn't change the frame size. But if I skip 
step 1, step 4 (evaluating s-f-a after resizing to 80x20) does change 
the frame size. And step 6 (s-f-a at size 80x32) does not.

So it seems the history of size changes now (?) affects which sizes are 
"impair".

Also, only height is important now: if height 20 is "impair", then I can 
resize the frame to any width with this height, and evaling s-f-a will 
shrink the frame in both dimensions by one char. Same for height 34 in 
the alternative scenario.

[foo.txt (text/plain, attachment)]

Previous Next

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