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

[Dmitry Gutov]

On 12/01/2023 11:31, martin rudalics wrote:
>  > So... the window manager works with "unscaled" pixels it has to 
> multiply by 2? That's why we try to send half the actual value?
>
> We send half the actual value because Robert (IIRC) has coded it that
> way.  I never scale here and so I can't tell whether that's the right
> approach.  Have a look at Bug#20432 where Jan says something about GTK
> messing things up.

He also says something about "doing things correctly in the trunk now".

>  > I was talking about the Scenario 3: the frame dimensions (pixelwise) 
> didn't change in it.
>
> Please tell me precisely where it didn't change.  The only cases where
> it did not change are the last two lines below.  And these represent the
> cases we wanted to fix.

The scenario number 3 (where both dimensions are off by 1).

The last two lines are indeed the ones that were printed when I 
evaluated the set-face-attribute call.

I now re-read your previous message, and it made sense. No need to 
continue with this particular inquiry, thank you.

>  > Thank you, but I'm not sure my work is particularly affected by
>  > it. Having the frame width settle on 80 chars is pretty nice, I
>  > suppose, but after that I usually maximize the frame anyway. Or make
>  > it take half the screen.
>
> Make it take half the screen?  This works here (xfwm4) only with
> 'frame-resize-pixelwise' enabled.

Seems to work fine here (in GNOME) either way. But it's possible that my 
screen width is just a convenient multiple of a char width, or very 
close. Anyway, I don't stay with side-by-side configuration for a long 
time either, it's mostly for bug reporting and associated testing.

>  > It would be nice, though, to avoid the frame size contortions during
>  > startup. I think it goes through 4 different sizes, at least. This
>  > patch doesn't seem to change the number of transitions, however.
>
> Conceptually, most of these contortions should happen with a yet
> invisible frame.  Also, font-related contortions are a pain because
> (IIUC) it takes some time to get the size of the default font as
> specified by the user's init file.

In an ideal world, I would expect this to result in just 2 frame 
configurations: before and after the default face was changed. Oh well.

> If Emacs were to start with a fixed
> initial pixel size, things were easier.  After all, Emacs is the only
> application I know that specifies the size of the initial window WRT
> some user specified font.
>
> But don't worry: When you are using a separate minibuffer frame, Emacs
> will start with one frame, create two additional ones and delete the
> first one afterwards.  That's what I call real contortions.

Sounds fun.

>  > If you send the patch together with a commit message, I can install it
>  > no problem (to the release branch or to master, whatever it deemed to
>  > be the best in this case).
>
> I'll try to come up with a few comments in the code so you can install
> it on master.  We might be able to simplify it later using the idea I
> had for Bug#60585.  But there so far I was not able to convince anyone
> of trying the patch I sent - and that one is much more involved.

I have tried it, but it seems to make no difference over here.

I cannot reproduce the problem reported in bug#60585, with or without 
that patch (with GNOME).

It doesn't seem to change anything WRT behavior discussed in this one.