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

[martin rudalics]

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