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