bug-gnu-emacs
[Top][All Lists]
Advanced

[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: martin rudalics
Subject: bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong
Date: Wed, 28 Dec 2022 18:35:51 +0100

> It certainly does work. One of the changes I saw right away is the
> width of the frame right after startup with my config increased from
> 84 to 90 columns.

What are you asking for in your configuration?

> Not sure if it's good or bad, so let's go back to
> the behavior with '-Q'.
>
> The height stopped shrinking.
>
> The width started growing. :-D

Repeatedly?

> I don't know if *foo* is helpful here yet, but here you go:

Not for the width.  But that's another issue.  If mutter complains about
the width not conforming to the (+ base_width (* width_inc N)) rule,
then we have already lost when the sum of fringes and scroll bar is not
a multiple of the frame's column width.  Which means, you get a "wrong"
size without any scaling and you may be lucky if that scaling does not
propagate during further 'set-face-attribute' calls.  Does each setting
of 'set-face-attribute' increase the width or is it just the first one?

Strictly spoken, Emacs is wrong here and mutter is right.  But fixing
this is quite involved since we'd have to disentangle those insane
FRAME_TEXT_COLS_TO_PIXEL_WIDTH and FRAME_TEXT_LINES_TO_PIXEL_HEIGHT
macros into xg_frame_set_char_size which would constitute a real pain.
More precisely, we'd have to treat scroll bars, fringes and internal
border like menu and toolbar and count them into the base_width value.

Try the attached which should work for any scaling and tell me what
happens now - in particular what the initial frame size is and whether
the frame grows or shrinks repeatedly.

martin

Attachment: x_scale_font.diff
Description: Text Data


reply via email to

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