GNU bug report logs -
#52493
29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong
Previous Next
Full log
Message #350 received at 52493 <at> debbugs.gnu.org (full text, mbox):
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).
This bug report was last modified 2 years and 249 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.