Package: emacs;
Reported by: Dmitry Gutov <dgutov <at> yandex.ru>
Date: Tue, 14 Dec 2021 23:45:01 UTC
Severity: normal
Found in version 29.0.50
View this message in rfc822 format
From: Dmitry Gutov <dgutov <at> yandex.ru> To: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org> Cc: rpluim <at> gmail.com, 52493 <at> debbugs.gnu.org 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
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.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.