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: Mon, 23 Jan 2023 00:25:19 +0200

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

On 22/01/2023 11:54, martin rudalics wrote:
>  >> 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.
> 
> You mean the ones where you resized a frame with the mouse by 16 or 36
> pixels with a character size of 17x37?

I guess so.

>  > 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.
> 
> Do you mean that 80x36 according to GNOME is 80x36 according to our
> internal measurements> while 80x20 to GNOME is 76x20 according to our
> internal measurements?

Not at all, I just got a little tired looking up our internal 
measurements every time. GNOME's measurements, OTOH, are listed under 
the mouse while I'm resizing the window.

I wasn't sure you really needed the internal ones here, so at some steps 
I only mentioned GNOME's ones.

>  > 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".
> 
> Didn't we always have that?

Not to my recollection. If the current pixel dimensions of the frame are 
FONT_HEIGHT*LINES-1, wouldn't that be a stable condition?

I could be wrong, though.

> The present code simply tries to reduce
> some noise when setting the font would otherwise cause a resize of a few
> pixels.

Cool.

>  > 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.
> 
> Please try the next patch so at least the initial size becomes
> reasonable again.

It does, thank you.

Here's a new scenario (very much similar to the old one):

1. Evaluate s-f-a twice.
2. Resize to 80x18 (internally it's 76x18).
3. Evaluate s-f-a twice.

The transcript attached, in case it's useful. But I guess, as per the 
previous discussion, this is the point where we could stop, with no 
further improvement feasible.

[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.