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

From: martin rudalics <[email-masked]>
Date: Thu, 29 Dec 2022 10:05:48 +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?
 >
 > With your latest patch it's slightly different (the max width is 84).

What is the "max width"?  The interesting return values are those of
(frame-text-width), (frame-text-cols) and (frame-char-width) so we can
relate the previous ones.

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

I'm quite sure that this is due to the scroll bar width and the fringes.
You could try to make these a multiple of (frame-char-width).  That is

(+ (frame-parameter nil 'scroll-bar-width)
    (frame-parameter nil 'left-fringe)
    (frame-parameter nil 'right-fringe))

would have to equal (* N (frame-char-width)) for some N >= 0.

 > So it seems like your latest patch doesn't change this behavior in any significant way. Still either 80 or 84, at random.
[...]
 > 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")

No idea.  You could try to step through normal_char_ascent_descent (best
when called from get_font_ascent_descent) for each of these fonts and
find out whether and how they differ.

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

So we at least have the improvement that the frame does not change size
for repeated, apparently idempotent, invocations.  Right?

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

Does shrinking the height with the mouse work as expected?  I'm quite
confident that neither of these can work reliably - after all, the one
pixel lost during rounding will continue to affect the intuitive
behavior.  I'd say that it's already a success when attempting to shrink
the frame with the mouse does not increase it initially.

Our handling of size hints is antediluvian.  In particular when
'frame-resize-pixelwise' is nil and on the other end a presumably
Teutonic WM designer interprets size hints literally.  I can try to come
up with a patch for these but don't expect too much.

martin