GNU bug report logs -
#52493
29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong
Previous Next
Full log
View this message in rfc822 format
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.
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.