[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face
From: |
Dmitry Gutov |
Subject: |
bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong |
Date: |
Thu, 12 Jan 2023 02:34:01 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 |
On 10/01/2023 14:05, martin rudalics wrote:
>> Here, for example, a maximized frame does not have the "right
>> height".
>
> Yeah ok, but none of the frames were maximized in those scenarios.
I mentioned it because that's how it usually can be reproduced easily
with emacs -Q.
> And the resizing by mouse "snapped" to the provided grid.
The resolution of that grid is specified by Emacs via these four lines
size_hints.width_inc = frame_resize_pixelwise ? 1 :
FRAME_COLUMN_WIDTH (f);
size_hints.height_inc = frame_resize_pixelwise ? 1 :
FRAME_LINE_HEIGHT (f);
size_hints.width_inc /= scale;
size_hints.height_inc /= scale;
If you scale by 2 and you have a font with impair sizes, you lose one
pixel and the grid will be smaller than the character size. If we round
up in the last two lines, the grid will be larger than the character
size by one pixel.
So... the window manager works with "unscaled" pixels it has to multiply
by 2? That's why we try to send half the actual value?
If we do not scale, the grid will have a resolution
of two characters. What would you prefer?
The current behavior seems more intuitive. Too bad we can't make it
behave precisely, but oh well.
> I'm probably out of my depth here, but with 2x scaling, shouldn't the
> height increment just be 2x larger than the original one? If N is
> integer, 2xN must be an integer as well.
You're scaling down whatever you display probably because otherwise
displayed objects would appear to small for your eyes. That is, while
Emacs lives in a 4000x2000 pixels world say, it's presented to your eyes
in a 2000x1000 pixels form.
That makes sense.
> Pixel dimensions do change in this scenario. But not the reported
text height.
Right. That's what rounding is all about
>> xg_frame_resized old native pixels 1424x1368 new native pixels
1408x1368
>> adjust_frame_size old native pixels 1424x1368 new native pixels
1408x1368 old text pixels 1376x1368 new text pixels 1360x1368 old text
chars 80x36 new text chars 80x36
>> xg_frame_resized old native pixels 1408x1368 new native pixels
1408x1332
>> adjust_frame_size old native pixels 1408x1368 new native pixels
1408x1332 old text pixels 1360x1368 new text pixels 1360x1332 old text
chars 80x36 new text chars 80x36
>>
>> represent two mouse operations that resize the frame by 16 pixels,
first
>> the width, then the height. Both are less that the character size so
>> while again the size of the frame should have changed, the numbers of
>> text characters didn't.
>
> The frame size didn't change either, however.
That's not what the numbers say. The first time, the width changed from
1424 to 1408 pixels. The second time, the height changed from 1368 to
1332 pixels.
I was talking about the Scenario 3: the frame dimensions (pixelwise)
didn't change in it.
> All right. Where do we go from here?
I think you should use the attached in your daily work. It's the same
as before with the tracing code omitted. If there are bigger problems,
use the former patch and post me the contents of *foo*.
Thank you, but I'm not sure my work is particularly affected by it.
Having the frame width settle on 80 chars is pretty nice, I suppose, but
after that I usually maximize the frame anyway. Or make it take half the
screen.
I believe getting the details right is important, but it's probably not
worth too much as a personal patch.
It would be nice, though, to avoid the frame size contortions during
startup. I think it goes through 4 different sizes, at least. This patch
doesn't seem to change the number of transitions, however.
> The usability problems remaining are very minor, so if you're saying
Emacs is going right thing, we might as well go with the latest patch
and call it a day. Thank you.
Note that I won't install anything in the near future because I've given
up synching with the repository. The last time I did, I spent a couple
of weeks to fix whatever got broken here.
Is there anything I can do to help? Your patch applies cleanly to the
emacs-29 branch, at least.
If you send the patch together with a commit message, I can install it
no problem (to the release branch or to master, whatever it deemed to be
the best in this case).
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, (continued)
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, Eric Abrahamsen, 2023/01/09
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, martin rudalics, 2023/01/07
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, Dmitry Gutov, 2023/01/08
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, martin rudalics, 2023/01/09
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, Dmitry Gutov, 2023/01/09
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, martin rudalics, 2023/01/10
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong,
Dmitry Gutov <=
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, martin rudalics, 2023/01/12
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, Robert Pluim, 2023/01/12
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, martin rudalics, 2023/01/12
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, Dmitry Gutov, 2023/01/12
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, Dmitry Gutov, 2023/01/12
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, martin rudalics, 2023/01/13
- 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, Dmitry Gutov, 2023/01/15
- 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, martin rudalics, 2023/01/16
- 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, Dmitry Gutov, 2023/01/16
- 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, martin rudalics, 2023/01/16