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: Dmitry Gutov
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: Sun, 22 Jan 2023 03:56:10 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

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.

Attachment: foo.txt
Description: Text document


reply via email to

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