[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: |
Dmitry Gutov |
Subject: |
bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong |
Date: |
Fri, 30 Dec 2022 00:29:02 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 |
On 29/12/2022 11:05, 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).
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.
Max among the return values of (frame-text-cols). With the next-to-last
patch it was 90.
> 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.
When frame-text-cols is 84, it's (+ 32 8 8) = 48, frame-char-width=17
When frame-text-cols is 80, all the above values are the same.
Oh, BTW, I have menu-bar, scroll-bar and tool-bar all disabled. The
fringes should be on, though.
> 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.
I'm reasonably certain it's the same font.
Evaluating either form ends up with the same face definition, IIUC. At
least the output of 'M-x describe-face RET default' is exactly the same
after either (I checked with 'diff'):
Family: Inconsolata LGC
Foundry: PfEd
Width: normal
Height: 109
Weight: regular
Slant: normal
Foreground: black
DistantForeground: unspecified
Background: white
Underline: nil
Overline: nil
Strike-through: nil
Box: nil
Inverse: nil
Stipple: nil
Font: #<font-object -PfEd-Inconsolata
LGC-regular-normal-normal-*-29-*-*-*-m-0-iso10646-1>
Fontset: -PfEd-Inconsolata
LGC-regular-normal-normal-*-29-*-*-*-m-0-fontset-auto2
Extend: nil
Inherit: nil
If you think it will help, I can still try stepping through the
functions you mentioned, but no earlier than tomorrow.
> 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?
For some frame widths it does not. For others (for ranges of widths) --
it does.
> 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.
Resizing with the mouse works without any apparent glitches. The corner
of the frame follows the mouse almost exactly, within the margin of a
char's height/width (when resizing is not pixelwise).
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.
Thanks.
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, (continued)
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, Dmitry Gutov, 2022/12/25
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, martin rudalics, 2022/12/25
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, Dmitry Gutov, 2022/12/25
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, martin rudalics, 2022/12/26
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, Dmitry Gutov, 2022/12/27
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, martin rudalics, 2022/12/28
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, Dmitry Gutov, 2022/12/28
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, martin rudalics, 2022/12/28
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, Dmitry Gutov, 2022/12/28
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, martin rudalics, 2022/12/29
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong,
Dmitry Gutov <=
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, martin rudalics, 2022/12/30
- bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, martin rudalics, 2022/12/31
bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, Dmitry Gutov, 2022/12/21
bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, Dmitry Gutov, 2022/12/20
bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong, Dmitry Gutov, 2022/12/21