bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong

[Dmitry Gutov]

On 28/12/2022 19:35, martin rudalics wrote:
>  > 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?

With your latest patch it's slightly different (the max width is 84).

But what I'm also seeing, is that even without your patch the starting 
frame width is not deterministic either: the frame resizes a few times 
during loading, and may end up at width either 80 or 84. I think I 
mentioned similar behavior in some other bug report too.

So it seems like your latest patch doesn't change this behavior in any 
significant way. Still either 80 or 84, at random.

>  > 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?

Yup. Without limit.

>  > 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?

Every one (at certain starting widths), just like it was with the 
shrinking of height.

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

I'm sure you are right, but before we continue the thorough 
investigation, do you have any idea why

 (set-face-attribute 'default nil :height 110 :family "InconsolataLGC")

exhibits this kooky behavior, while

 (set-face-attribute 'default nil :height 110 :family "Inconsolata LGC")

does not? That might point to a weird kludge or workaround somewhere 
which just needs moving somewhere else.

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

Now the width shrinks. Not from all starting widths, but from many of them.

Suppose the starting width is 80 (that's what frame-text-cols returns). 
Evaluating the set-face-attribute form changes the frame size once, but 
not the width in columns. Successive invocations don't change the frame 
size.

I increase the frame to width 112 with a mouse. Doesn't shrink. 111-108 
- nope.

I resize it to 107 (according to frame-text-cols; the wm reports 
109x36), and evaluating the form shrinks the frame by 2 columns. That 
repeats until frame-text-cols is 96.

Widths 96-92 don't shrink.

I resize to 91 - it continues shrinking (in steps of 2) until 80. 80-76 
don't shrink.

75 - shrinks until 64. And so on.