GNU bug report logs -
#52493
29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong
Previous Next
To reply to this bug, email your comments to 52493 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Tue, 14 Dec 2021 23:45:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dmitry Gutov <dgutov <at> yandex.ru>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 14 Dec 2021 23:45:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
It's a weird scenario, but evaluating this in 'emacs -Q' will make
characters render more narrowly (and a little shorter) than it did
previously:
(set-face-attribute 'default nil :height 110 :family "Inconsolata_dz")
See the attached screenshot with comparison (master is on the left).
This seems to happen with both Inconsolata_dz which I use and the
original Inconsolata (at least some version of it). The font file which
I use
resides is linked to at the bottom of
https://nodnod.net/posts/inconsolata-dz/.
It started to happen right after the changes required to use the
"proportional mode-line" were added. I was kind of waiting for somebody
else to report this problem. ;-( It makes master fairly unusable to me,
however.
Other fonts don't seem to have this effect.
Also, if I first evaluate this form, and then change the :family value
to "Hack", the font changes once (to a font with "normal" width) but
then no subsequent evaluations of this form with other values have any
effect on the used font-family (it is "stuck"), but the window shrinks a
little every time.
In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2021-11-11 built on potemkin
Repository revision: ebcba77d4c47ceff24115f80c2109916a6b425b1
Repository branch: scratch/etags-regen
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Ubuntu 20.04.3 LTS
[Screenshot from 2021-12-15 02-27-20.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Wed, 15 Dec 2021 14:59:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Wed, 15 Dec 2021 02:43:30 +0300
>
> It's a weird scenario, but evaluating this in 'emacs -Q' will make
> characters render more narrowly (and a little shorter) than it did
> previously:
>
> (set-face-attribute 'default nil :height 110 :family "Inconsolata_dz")
>
> See the attached screenshot with comparison (master is on the left).
Indeed, weird. What does the below show?
M-: (face-font 'default) RET
after you evaluate the above in "emacs -Q"? And how does it differ
from the same in a version of Emacs that predates the changes of the
mode-line face?
Also, what happens if you invoke Emacs like this:
$ emacs -Q -fn Inconsolata_dz
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Wed, 15 Dec 2021 22:45:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 15.12.2021 17:57, Eli Zaretskii wrote:
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Date: Wed, 15 Dec 2021 02:43:30 +0300
>>
>> It's a weird scenario, but evaluating this in 'emacs -Q' will make
>> characters render more narrowly (and a little shorter) than it did
>> previously:
>>
>> (set-face-attribute 'default nil :height 110 :family "Inconsolata_dz")
>>
>> See the attached screenshot with comparison (master is on the left).
>
> Indeed, weird. What does the below show?
>
> M-: (face-font 'default) RET
>
> after you evaluate the above in "emacs -Q"?
"-DAMA-Ubuntu Condensed-regular-normal-normal-*-29-*-*-*-*-0-iso10646-1"
So... not the right family and it's "condensed", for some reason.
For comparison,
(set-face-attribute 'default nil :height 110 :family "Ubuntu")
results in
"-DAMA-Ubuntu-regular-normal-normal-*-29-*-*-*-*-0-iso10646-1"
And by default (without any set-face-attribute calls),
(face-font 'default) evaluates to
"-DAMA-Ubuntu Mono-regular-normal-normal-*-35-*-*-*-m-0-iso10646-1"
> And how does it differ
> from the same in a version of Emacs that predates the changes of the
> mode-line face?
Current emacs-28 returns
"-PfEd-Inconsolata_dz-normal-normal-normal-*-29-*-*-*-m-0-iso10646-1"
Regarding "version of Emacs that predates", I wasn't sure which commit
to pick exactly, but 756b8a5f1bd28aeadc804 also returns that value, and
doesn't have the described problem.
> Also, what happens if you invoke Emacs like this:
>
> $ emacs -Q -fn Inconsolata_dz
It doesn't look as narrow, and (face-font 'default) evaluates to
"-PfEd-Inconsolata_dz-medium-normal-normal-*-32-*-*-*-m-0-iso10646-1"
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 16 Dec 2021 07:30:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Cc: 52493 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Thu, 16 Dec 2021 01:43:31 +0300
>
> >> (set-face-attribute 'default nil :height 110 :family "Inconsolata_dz")
> >>
> >> See the attached screenshot with comparison (master is on the left).
> >
> > Indeed, weird. What does the below show?
> >
> > M-: (face-font 'default) RET
> >
> > after you evaluate the above in "emacs -Q"?
>
> "-DAMA-Ubuntu Condensed-regular-normal-normal-*-29-*-*-*-*-0-iso10646-1"
>
> So... not the right family and it's "condensed", for some reason.
>
> For comparison,
>
> (set-face-attribute 'default nil :height 110 :family "Ubuntu")
>
> results in
>
> "-DAMA-Ubuntu-regular-normal-normal-*-29-*-*-*-*-0-iso10646-1"
>
> And by default (without any set-face-attribute calls),
>
> (face-font 'default) evaluates to
>
> "-DAMA-Ubuntu Mono-regular-normal-normal-*-35-*-*-*-m-0-iso10646-1"
>
> > And how does it differ
> > from the same in a version of Emacs that predates the changes of the
> > mode-line face?
>
> Current emacs-28 returns
>
> "-PfEd-Inconsolata_dz-normal-normal-normal-*-29-*-*-*-m-0-iso10646-1"
>
> Regarding "version of Emacs that predates", I wasn't sure which commit
> to pick exactly, but 756b8a5f1bd28aeadc804 also returns that value, and
> doesn't have the described problem.
>
> > Also, what happens if you invoke Emacs like this:
> >
> > $ emacs -Q -fn Inconsolata_dz
>
> It doesn't look as narrow, and (face-font 'default) evaluates to
>
> "-PfEd-Inconsolata_dz-medium-normal-normal-*-32-*-*-*-m-0-iso10646-1"
Thanks. I think this means that Emacs 29 on master now rejects the
Inconsolata_dz font for some reason, or thinks it finds a better
match. The fact that it picks a condensed family is probably
secondary; the main issue here is that the font family you requested
is rejected.
Does that family have the regular weight? If not, maybe that's the
reason it is rejected, and you need to also require some specific
:weight value in your set-face-attribute call.
Also, maybe running
$ FC_DEBUG=1282 emacs -Q
will give us a clue of what happens. See
https://www.freedesktop.org/software/fontconfig/fontconfig-user.html#DEBUG
for where I took that weird value.
Robert, any other ideas?
If this doesn't help, I'm afraid the only way forward is to step
through the code which selects a font when you specify the family for
the default face, and see what happens there and why.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 16 Dec 2021 13:03:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 16.12.2021 10:29, Eli Zaretskii wrote:
>> Cc: 52493 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Date: Thu, 16 Dec 2021 01:43:31 +0300
>>
>>>> (set-face-attribute 'default nil :height 110 :family "Inconsolata_dz")
>>>>
>>>> See the attached screenshot with comparison (master is on the left).
>>>
>>> Indeed, weird. What does the below show?
>>>
>>> M-: (face-font 'default) RET
>>>
>>> after you evaluate the above in "emacs -Q"?
>>
>> "-DAMA-Ubuntu Condensed-regular-normal-normal-*-29-*-*-*-*-0-iso10646-1"
>>
>> So... not the right family and it's "condensed", for some reason.
>>
>> For comparison,
>>
>> (set-face-attribute 'default nil :height 110 :family "Ubuntu")
>>
>> results in
>>
>> "-DAMA-Ubuntu-regular-normal-normal-*-29-*-*-*-*-0-iso10646-1"
>>
>> And by default (without any set-face-attribute calls),
>>
>> (face-font 'default) evaluates to
>>
>> "-DAMA-Ubuntu Mono-regular-normal-normal-*-35-*-*-*-m-0-iso10646-1"
>>
>>> And how does it differ
>>> from the same in a version of Emacs that predates the changes of the
>>> mode-line face?
>>
>> Current emacs-28 returns
>>
>> "-PfEd-Inconsolata_dz-normal-normal-normal-*-29-*-*-*-m-0-iso10646-1"
>>
>> Regarding "version of Emacs that predates", I wasn't sure which commit
>> to pick exactly, but 756b8a5f1bd28aeadc804 also returns that value, and
>> doesn't have the described problem.
>>
>>> Also, what happens if you invoke Emacs like this:
>>>
>>> $ emacs -Q -fn Inconsolata_dz
>>
>> It doesn't look as narrow, and (face-font 'default) evaluates to
>>
>> "-PfEd-Inconsolata_dz-medium-normal-normal-*-32-*-*-*-m-0-iso10646-1"
>
> Thanks. I think this means that Emacs 29 on master now rejects the
> Inconsolata_dz font for some reason, or thinks it finds a better
> match.
Despite 'emacs -Q -fn Inconsolata_dz' having the intended effect?
> The fact that it picks a condensed family is probably
> secondary; the main issue here is that the font family you requested
> is rejected.
>
> Does that family have the regular weight? If not, maybe that's the
> reason it is rejected, and you need to also require some specific
> :weight value in your set-face-attribute call.
Although yes, something to that effect seems to be going on. But
specifying different values of :weight doesn't help either (regulal,
medium, light, bold, extra-bold).
Nor :width (condensed/semi-condensed/normal).
> Also, maybe running
>
> $ FC_DEBUG=1282 emacs -Q
>
> will give us a clue of what happens. See
>
> https://www.freedesktop.org/software/fontconfig/fontconfig-user.html#DEBUG
>
> for where I took that weird value.
I've recorded the log, but it's 92 MB.
It's uploaded here: https://www.filemail.com/d/uplporttqgfaive
(The page probably requires JS, and if somehow it doesn't work on your
system, try ftp://uplporttqgfaive:filemail <at> 3012.filemail.com/)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 16 Dec 2021 13:33:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Cc: 52493 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Thu, 16 Dec 2021 16:01:26 +0300
>
> > Thanks. I think this means that Emacs 29 on master now rejects the
> > Inconsolata_dz font for some reason, or thinks it finds a better
> > match.
>
> Despite 'emacs -Q -fn Inconsolata_dz' having the intended effect?
Yes. The -fn argument forces Emacs to use the specified font, whereas
:family is much more general and doesn't force the use of a specific
font.
> > The fact that it picks a condensed family is probably
> > secondary; the main issue here is that the font family you requested
> > is rejected.
> >
> > Does that family have the regular weight? If not, maybe that's the
> > reason it is rejected, and you need to also require some specific
> > :weight value in your set-face-attribute call.
>
> Although yes, something to that effect seems to be going on. But
> specifying different values of :weight doesn't help either (regulal,
> medium, light, bold, extra-bold).
If playing with :weight didn't help, what other evidence did you see
that this issue is related?
> > Also, maybe running
> >
> > $ FC_DEBUG=1282 emacs -Q
> >
> > will give us a clue of what happens. See
> >
> > https://www.freedesktop.org/software/fontconfig/fontconfig-user.html#DEBUG
> >
> > for where I took that weird value.
>
> I've recorded the log, but it's 92 MB.
>
> It's uploaded here: https://www.filemail.com/d/uplporttqgfaive
Thanks, I will try to take a look and see if I spot something of
interest.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 16 Dec 2021 13:44:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 16.12.2021 16:31, Eli Zaretskii wrote:
>> Cc:52493 <at> debbugs.gnu.org
>> From: Dmitry Gutov<dgutov <at> yandex.ru>
>> Date: Thu, 16 Dec 2021 16:01:26 +0300
>>
>>> Thanks. I think this means that Emacs 29 on master now rejects the
>>> Inconsolata_dz font for some reason, or thinks it finds a better
>>> match.
>> Despite 'emacs -Q -fn Inconsolata_dz' having the intended effect?
> Yes. The -fn argument forces Emacs to use the specified font, whereas
> :family is much more general and doesn't force the use of a specific
> font.
>
>>> The fact that it picks a condensed family is probably
>>> secondary; the main issue here is that the font family you requested
>>> is rejected.
>>>
>>> Does that family have the regular weight? If not, maybe that's the
>>> reason it is rejected, and you need to also require some specific
>>> :weight value in your set-face-attribute call.
>> Although yes, something to that effect seems to be going on. But
>> specifying different values of :weight doesn't help either (regulal,
>> medium, light, bold, extra-bold).
> If playing with :weight didn't help, what other evidence did you see
> that this issue is related?
Related to not being able to select that family (as opposed to
rendering it wrong, for instance).
I also tried different scenarios which seemed to help (choose another
family, and a different weight, and then this one), but apparently they
ended up selecting a different family ultimately, rather than the one I
specified.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 16 Dec 2021 14:10:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Cc: rpluim <at> gmail.com, 52493 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Thu, 16 Dec 2021 16:42:08 +0300
>
> >>> Does that family have the regular weight? If not, maybe that's the
> >>> reason it is rejected, and you need to also require some specific
> >>> :weight value in your set-face-attribute call.
> >> Although yes, something to that effect seems to be going on. But
> >> specifying different values of :weight doesn't help either (regulal,
> >> medium, light, bold, extra-bold).
> > If playing with :weight didn't help, what other evidence did you see
> > that this issue is related?
>
> Related to not being able to select that family (as opposed to
> rendering it wrong, for instance).
>
> I also tried different scenarios which seemed to help (choose another
> family, and a different weight, and then this one), but apparently they
> ended up selecting a different family ultimately, rather than the one I
> specified.
I see.
If you can afford it, please try building the master branch at commit
4e9764e. This is one commit before Lars installed the support for the
'medium' value of :weight, and the question is whether that change
caused what you see.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 16 Dec 2021 14:59:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 16.12.2021 17:08, Eli Zaretskii wrote:
> If you can afford it, please try building the master branch at commit
> 4e9764e. This is one commit before Lars installed the support for the
> 'medium' value of :weight, and the question is whether that change
> caused what you see.
Yup, this one seems to be working fine.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 16 Dec 2021 15:16:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Cc: rpluim <at> gmail.com, 52493 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Thu, 16 Dec 2021 17:57:04 +0300
>
> On 16.12.2021 17:08, Eli Zaretskii wrote:
> > If you can afford it, please try building the master branch at commit
> > 4e9764e. This is one commit before Lars installed the support for the
> > 'medium' value of :weight, and the question is whether that change
> > caused what you see.
>
> Yup, this one seems to be working fine.
Hm, but then I don't understand why using ":weight medium" in
set-face-attribute didn't help you to get the font you wanted. That's
the main change of that commit, AFAIU.
Maybe try to change the weight first and the family after it?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 16 Dec 2021 15:35:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 16 Dec 2021 17:15:18 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: rpluim <at> gmail.com, 52493 <at> debbugs.gnu.org
>
> Hm, but then I don't understand why using ":weight medium" in
> set-face-attribute didn't help you to get the font you wanted. That's
> the main change of that commit, AFAIU.
>
> Maybe try to change the weight first and the family after it?
Does that font have a 'regular' weight variety? If not, I think this
is a variant of the same issue I fixed in bug#51768: we now request a
'regular' weight when a face specifies the family, and a font which
doesn't have 'regular' is rejected. So maybe the kludge that I added
to font.c only for MS-Windows should be in effect on Posix systems as
well?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 16 Dec 2021 15:39:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 16.12.2021 18:15, Eli Zaretskii wrote:
>> Cc: rpluim <at> gmail.com, 52493 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Date: Thu, 16 Dec 2021 17:57:04 +0300
>>
>> On 16.12.2021 17:08, Eli Zaretskii wrote:
>>> If you can afford it, please try building the master branch at commit
>>> 4e9764e. This is one commit before Lars installed the support for the
>>> 'medium' value of :weight, and the question is whether that change
>>> caused what you see.
>>
>> Yup, this one seems to be working fine.
>
> Hm, but then I don't understand why using ":weight medium" in
> set-face-attribute didn't help you to get the font you wanted. That's
> the main change of that commit, AFAIU.
In another news, 65fd3ca8 (the following commit that added 'medium')
doesn't trigger the problem either.
> Maybe try to change the weight first and the family after it?
Doesn't help.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 16 Dec 2021 15:44:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 16.12.2021 18:34, Eli Zaretskii wrote:
>> Date: Thu, 16 Dec 2021 17:15:18 +0200
>> From: Eli Zaretskii<eliz <at> gnu.org>
>> Cc:rpluim <at> gmail.com,52493 <at> debbugs.gnu.org
>>
>> Hm, but then I don't understand why using ":weight medium" in
>> set-face-attribute didn't help you to get the font you wanted. That's
>> the main change of that commit, AFAIU.
>>
>> Maybe try to change the weight first and the family after it?
> Does that font have a 'regular' weight variety?
I'm not sure how to check. But in the font viewer, in the details,
Inconsolata has "Style: Medium", and Inconsolata_dz has "Style: dz".
Most of the others (including InconsolataLGC) have "Regular" in that field.
> If not, I think this
> is a variant of the same issue I fixed in bug#51768: we now request a
> 'regular' weight when a face specifies the family, and a font which
> doesn't have 'regular' is rejected. So maybe the kludge that I added
> to font.c only for MS-Windows should be in effect on Posix systems as
> well?
If you have a patch, I can test.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 16 Dec 2021 16:56:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Cc: rpluim <at> gmail.com, 52493 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Thu, 16 Dec 2021 18:36:59 +0300
>
> In another news, 65fd3ca8 (the following commit that added 'medium')
> doesn't trigger the problem either.
What about 84bf954? does it introduce the problem?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 16 Dec 2021 16:58:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Cc: rpluim <at> gmail.com, 52493 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Thu, 16 Dec 2021 18:42:21 +0300
>
> > Does that font have a 'regular' weight variety?
>
> I'm not sure how to check. But in the font viewer, in the details,
> Inconsolata has "Style: Medium", and Inconsolata_dz has "Style: dz".
>
> Most of the others (including InconsolataLGC) have "Regular" in that field.
>
> > If not, I think this
> > is a variant of the same issue I fixed in bug#51768: we now request a
> > 'regular' weight when a face specifies the family, and a font which
> > doesn't have 'regular' is rejected. So maybe the kludge that I added
> > to font.c only for MS-Windows should be in effect on Posix systems as
> > well?
>
> If you have a patch, I can test.
There's part of the font_delete_unmatched function that's conditioned
on HAVE_NTGUI. If you remove the condition (so that the code there is
unconditionally compiled) and rebuild, does the problem go away?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 17 Dec 2021 00:15:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 16.12.2021 19:54, Eli Zaretskii wrote:
>> Cc:rpluim <at> gmail.com,52493 <at> debbugs.gnu.org
>> From: Dmitry Gutov<dgutov <at> yandex.ru>
>> Date: Thu, 16 Dec 2021 18:36:59 +0300
>>
>> In another news, 65fd3ca8 (the following commit that added 'medium')
>> doesn't trigger the problem either.
> What about 84bf954? does it introduce the problem?
No, both it and its parent have the problem. Which kind of makes sense,
since the commit doesn't seem to change any fundamentals, just how the
mode-line looks.
I did 'git bisect', and it points to dae3c4e89b27.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 17 Dec 2021 00:51:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 16.12.2021 19:56, Eli Zaretskii wrote:
> There's part of the font_delete_unmatched function that's conditioned
> on HAVE_NTGUI. If you remove the condition (so that the code there is
> unconditionally compiled) and rebuild, does the problem go away?
Yup! Seems to help.
This is one additional piece of misbehavior (perhaps unrelated) that
really caught my eye during these tests:
When I evaluate
(set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
(this variation of the font doesn't have the original problem), the
height of the window shrinks, unless the window is maximized.
If I evaluate it multiple times, the height shrinks every time I do that
(stopping at height 5, when even the minibuffer becomes inaccessible).
If I evaluate
(set-face-attribute 'default nil :height 110 :family "Inconsolata_dz")
(with your fix applied), it only shrinks twice (from 33 to 29 to 27, as
reported by (window-height)). And then stops shrinking on subsequent
attempts.
Doing the same with InconsolataLGC on the latter build still makes it
shrink indefinitely.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 17 Dec 2021 07:38:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Cc: rpluim <at> gmail.com, 52493 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Fri, 17 Dec 2021 03:49:36 +0300
>
> On 16.12.2021 19:56, Eli Zaretskii wrote:
> > There's part of the font_delete_unmatched function that's conditioned
> > on HAVE_NTGUI. If you remove the condition (so that the code there is
> > unconditionally compiled) and rebuild, does the problem go away?
>
> Yup! Seems to help.
Lars, do we make that kludge unconditionally compiled on all systems?
The change which Dmitry's bisection found as the culprit cannot be
undone, I think, because without it we cannot support medium weight
separately from regular. The change I made in font.c is the second
best, I think (or at least I couldn't think of a better one) for
people who have long-time setups which worked until now because we
treated medium and regular as the same weight.
> When I evaluate
>
> (set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
>
> (this variation of the font doesn't have the original problem), the
> height of the window shrinks, unless the window is maximized.
>
> If I evaluate it multiple times, the height shrinks every time I do that
> (stopping at height 5, when even the minibuffer becomes inaccessible).
The original shrinking is expected, I think, but the subsequent ones
shouldn't happen. Martin, could you look into this, perhaps?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 17 Dec 2021 07:48:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 52493 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Lars, do we make that kludge unconditionally compiled on all systems?
Yes, I think that makes sense.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 17 Dec 2021 08:39:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Dmitry Gutov <dgutov <at> yandex.ru>, martin rudalics <rudalics <at> gmx.at>,
> rpluim <at> gmail.com, 52493 <at> debbugs.gnu.org
> Date: Fri, 17 Dec 2021 08:46:58 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Lars, do we make that kludge unconditionally compiled on all systems?
>
> Yes, I think that makes sense.
I installed the change. Dmitry, please see if the original problem is
indeed fixed.
I will not close the bug anyway, because of the resizing issue that
still needs investigating.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 17 Dec 2021 12:32:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 17.12.2021 10:37, Eli Zaretskii wrote:
>> Cc: rpluim <at> gmail.com, 52493 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Date: Fri, 17 Dec 2021 03:49:36 +0300
>>
>> On 16.12.2021 19:56, Eli Zaretskii wrote:
>>> There's part of the font_delete_unmatched function that's conditioned
>>> on HAVE_NTGUI. If you remove the condition (so that the code there is
>>> unconditionally compiled) and rebuild, does the problem go away?
>>
>> Yup! Seems to help.
>
> Lars, do we make that kludge unconditionally compiled on all systems?
> The change which Dmitry's bisection found as the culprit cannot be
> undone, I think, because without it we cannot support medium weight
> separately from regular.
Are we sure the bisected change (dae3c4e89b27) itself doesn't need a
tweak? From all the explanations here, I would expect
(set-face-attribute 'default nil :height 110 :weight 'medium :family
"Inconsolata")
to work correctly even without your "kludge". But it does not.
Like, okay, Inconsolata_dz has a weird "style" ("dz"), but the plain
Inconsolata is "Medium".
>> When I evaluate
>>
>> (set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
>>
>> (this variation of the font doesn't have the original problem), the
>> height of the window shrinks, unless the window is maximized.
>>
>> If I evaluate it multiple times, the height shrinks every time I do that
>> (stopping at height 5, when even the minibuffer becomes inaccessible).
>
> The original shrinking is expected, I think, but the subsequent ones
> shouldn't happen. Martin, could you look into this, perhaps?
Since I'm measuring window height in characters (rows) here and not in
pixels, I don't think even the first change should happen.
Though of course the window size in pixels should change.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 17 Dec 2021 13:03:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Cc: rpluim <at> gmail.com, 52493 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Fri, 17 Dec 2021 15:30:46 +0300
>
> > Lars, do we make that kludge unconditionally compiled on all systems?
> > The change which Dmitry's bisection found as the culprit cannot be
> > undone, I think, because without it we cannot support medium weight
> > separately from regular.
>
> Are we sure the bisected change (dae3c4e89b27) itself doesn't need a
> tweak? From all the explanations here, I would expect
>
> (set-face-attribute 'default nil :height 110 :weight 'medium :family
> "Inconsolata")
>
> to work correctly even without your "kludge". But it does not.
>
> Like, okay, Inconsolata_dz has a weird "style" ("dz"), but the plain
> Inconsolata is "Medium".
Plain Inconsolata is indeed medium, but Emacs now requests regular,
not medium, as the default weight. And, according to the Fc log you
posted, Inconsolata doesn't have a regular weight variety (whose value
should be 80, not 100).
> >> When I evaluate
> >>
> >> (set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
> >>
> >> (this variation of the font doesn't have the original problem), the
> >> height of the window shrinks, unless the window is maximized.
> >>
> >> If I evaluate it multiple times, the height shrinks every time I do that
> >> (stopping at height 5, when even the minibuffer becomes inaccessible).
> >
> > The original shrinking is expected, I think, but the subsequent ones
> > shouldn't happen. Martin, could you look into this, perhaps?
>
> Since I'm measuring window height in characters (rows) here and not in
> pixels, I don't think even the first change should happen.
>
> Though of course the window size in pixels should change.
Let's wait for Martin to chime in, he's the expert on this stuff.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 17 Dec 2021 13:23:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 17.12.2021 16:01, Eli Zaretskii wrote:
>> Cc: rpluim <at> gmail.com, 52493 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Date: Fri, 17 Dec 2021 15:30:46 +0300
>>
>>> Lars, do we make that kludge unconditionally compiled on all systems?
>>> The change which Dmitry's bisection found as the culprit cannot be
>>> undone, I think, because without it we cannot support medium weight
>>> separately from regular.
>>
>> Are we sure the bisected change (dae3c4e89b27) itself doesn't need a
>> tweak? From all the explanations here, I would expect
>>
>> (set-face-attribute 'default nil :height 110 :weight 'medium :family
>> "Inconsolata")
>>
>> to work correctly even without your "kludge". But it does not.
>>
>> Like, okay, Inconsolata_dz has a weird "style" ("dz"), but the plain
>> Inconsolata is "Medium".
>
> Plain Inconsolata is indeed medium, but Emacs now requests regular,
> not medium, as the default weight. And, according to the Fc log you
> posted, Inconsolata doesn't have a regular weight variety (whose value
> should be 80, not 100).
But when I specify :weight 'medium, shouldn't it request medium then?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 17 Dec 2021 13:47:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Cc: larsi <at> gnus.org, 52493 <at> debbugs.gnu.org, rpluim <at> gmail.com
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Fri, 17 Dec 2021 16:21:30 +0300
>
> >> Like, okay, Inconsolata_dz has a weird "style" ("dz"), but the plain
> >> Inconsolata is "Medium".
> >
> > Plain Inconsolata is indeed medium, but Emacs now requests regular,
> > not medium, as the default weight. And, according to the Fc log you
> > posted, Inconsolata doesn't have a regular weight variety (whose value
> > should be 80, not 100).
>
> But when I specify :weight 'medium, shouldn't it request medium then?
You didn't just specify medium, you specified both the family and the
weight. The implementation does it one attribute at a time (because
doing it together triggered other bugs), so at first Emacs attempts to
find a font with that family and the default weight. And without the
kludge in font.c, that font is rejected because it doesn't have
regular weight.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 17 Dec 2021 14:08:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 17.12.2021 16:46, Eli Zaretskii wrote:
>> Cc: larsi <at> gnus.org, 52493 <at> debbugs.gnu.org, rpluim <at> gmail.com
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Date: Fri, 17 Dec 2021 16:21:30 +0300
>>
>>>> Like, okay, Inconsolata_dz has a weird "style" ("dz"), but the plain
>>>> Inconsolata is "Medium".
>>>
>>> Plain Inconsolata is indeed medium, but Emacs now requests regular,
>>> not medium, as the default weight. And, according to the Fc log you
>>> posted, Inconsolata doesn't have a regular weight variety (whose value
>>> should be 80, not 100).
>>
>> But when I specify :weight 'medium, shouldn't it request medium then?
>
> You didn't just specify medium, you specified both the family and the
> weight. The implementation does it one attribute at a time (because
> doing it together triggered other bugs), so at first Emacs attempts to
> find a font with that family and the default weight. And without the
> kludge in font.c, that font is rejected because it doesn't have
> regular weight.
Feels counter-intuitive, but all right.
I've tested the latest master, and that problem is fixed. Thanks!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 17 Dec 2021 14:43:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Cc: larsi <at> gnus.org, 52493 <at> debbugs.gnu.org, rpluim <at> gmail.com
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Fri, 17 Dec 2021 17:06:05 +0300
>
> >> But when I specify :weight 'medium, shouldn't it request medium then?
> >
> > You didn't just specify medium, you specified both the family and the
> > weight. The implementation does it one attribute at a time (because
> > doing it together triggered other bugs), so at first Emacs attempts to
> > find a font with that family and the default weight. And without the
> > kludge in font.c, that font is rejected because it doesn't have
> > regular weight.
>
> Feels counter-intuitive, but all right.
The comments in the code point to bug#1127. Maybe that problem no
longer exists, and we could avoid doing that?
> I've tested the latest master, and that problem is fixed. Thanks!
Thanks for testing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 17 Dec 2021 19:18:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> When I evaluate
>
> (set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
>
> (this variation of the font doesn't have the original problem), the height of the window shrinks, unless the window is maximized.
When a frame is maximized, no implied resizing is done. With
(push 'font frame-inhibit-implied-resize)
a non-maximized frame should also keep its size in your case.
> If I evaluate it multiple times, the height shrinks every time I do
> that
This might be a rounding error or some misunderstanding wrt what the WM
(mutter in your case?) thinks our frame size is and what Emacs thinks.
In x_new_font (in xterm.c) we do
FRAME_COLUMN_WIDTH (f) = font->average_width;
...
FRAME_LINE_HEIGHT (f) = font_ascent + font_descent;
...
adjust_frame_size
(f, FRAME_COLS (f) * FRAME_COLUMN_WIDTH (f),
FRAME_LINES (f) * FRAME_LINE_HEIGHT (f), 3, false, Qfont);
which should have the effect that (frame-height) and (frame-width)
remain unaltered when changing the default font. Apparently, this fails
in your case.
> (stopping at height 5, when even the minibuffer becomes
> inaccessible
This is a separate issue I fixed here some time ago. But I don't
remember whether I pushed it and/or whether it requires additional
customizations to make it DTRT (it might depend on the ability to drop
window decorations one by one when a frame is shrunk).
> ).
> If I evaluate
>
> (set-face-attribute 'default nil :height 110 :family "Inconsolata_dz")
>
> (with your fix applied), it only shrinks twice (from 33 to 29 to 27, as reported by (window-height)). And then stops shrinking on subsequent attempts.
>
> Doing the same with InconsolataLGC on the latter build still makes it shrink indefinitely.
Here as above, stepping with GDB through the x_new_font code sketched
above might help tracking down this issue.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Wed, 21 Dec 2022 01:09:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 52493 <at> debbugs.gnu.org (full text, mbox):
Hi Martin,
Sorry I only got around to doing this now.
This seems to still be a problem in emacs-29, however.
On 17/12/2021 21:17, martin rudalics wrote:
> > When I evaluate
> >
> > (set-face-attribute 'default nil :height 110 :family
> "InconsolataLGC")
> >
> > (this variation of the font doesn't have the original problem), the
> height of the window shrinks, unless the window is maximized.
>
> When a frame is maximized, no implied resizing is done. With
>
> (push 'font frame-inhibit-implied-resize)
>
> a non-maximized frame should also keep its size in your case.
>
> > If I evaluate it multiple times, the height shrinks every time I do
> > that
>
> This might be a rounding error or some misunderstanding wrt what the WM
> (mutter in your case?) thinks our frame size is and what Emacs thinks.
> In x_new_font (in xterm.c) we do
Not sure if it's Mutter these days, but it's definitely GNOME Shell.
GNOME 43.1 now (I filed this issue with a much older GNOME).
> FRAME_COLUMN_WIDTH (f) = font->average_width;
> ...
> FRAME_LINE_HEIGHT (f) = font_ascent + font_descent;
> ...
> adjust_frame_size
> (f, FRAME_COLS (f) * FRAME_COLUMN_WIDTH (f),
> FRAME_LINES (f) * FRAME_LINE_HEIGHT (f), 3, false, Qfont);
>
> which should have the effect that (frame-height) and (frame-width)
> remain unaltered when changing the default font. Apparently, this fails
> in your case.
>
> > (stopping at height 5, when even the minibuffer becomes
> > inaccessible
>
> This is a separate issue I fixed here some time ago. But I don't
> remember whether I pushed it and/or whether it requires additional
> customizations to make it DTRT (it might depend on the ability to drop
> window decorations one by one when a frame is shrunk).
I've tried stepping through the function, and the height does shrink
when I evaluate the previously mentioned form. Not sure which of the
values are useful to you, which ones I should have printed along the
way. But see the debug log at the bottom.
All this with 'emacs -Q'. It might be because of a rounding error, but
maybe not. The bug happens with most window heights, but not with all.
E.g., it stayed stable at (frame-height) = 36. Set it to a larger value
- and it goes on shrinking until 36. Set it to a lower value (35 or
less), and it does on to shrink until 10 in small steps.
Here's the debugging log. This is just one iteration.
Thread 1 "emacs" hit Breakpoint 3, x_new_font (f=0x55555628e5e0,
font_object=XIL(0x555556287395), fontset=28) at xterm.c:26174
26174 FRAME_COLUMN_WIDTH (f) = font->average_width;
(gdb) p font->text_height
There is no member named text_height.
(gdb) p f->text_height
$7 = 1116
(gdb) xint
$8 = 279
(gdb) n
26175 get_font_ascent_descent (font, &font_ascent, &font_descent);
(gdb) n
26176 FRAME_LINE_HEIGHT (f) = font_ascent + font_descent;
(gdb) n
26179 FRAME_MENU_BAR_HEIGHT (f) = FRAME_MENU_BAR_LINES (f) *
FRAME_LINE_HEIGHT (f);
(gdb) c
Continuing.
Thread 1 "emacs" hit Breakpoint 3, x_new_font (f=0x55555628e5e0,
font_object=XIL(0x5555562d9865), fontset=28) at xterm.c:26174
26174 FRAME_COLUMN_WIDTH (f) = font->average_width;
(gdb) c
Continuing.
Thread 1 "emacs" hit Breakpoint 3, x_new_font (f=0x55555628e5e0,
font_object=XIL(0x555556287395), fontset=28) at xterm.c:26174
26174 FRAME_COLUMN_WIDTH (f) = font->average_width;
(gdb) n
26175 get_font_ascent_descent (font, &font_ascent, &font_descent);
(gdb) n
26176 FRAME_LINE_HEIGHT (f) = font_ascent + font_descent;
(gdb) n
26179 FRAME_MENU_BAR_HEIGHT (f) = FRAME_MENU_BAR_LINES (f) *
FRAME_LINE_HEIGHT (f);
(gdb) n
26182 FRAME_TAB_BAR_HEIGHT (f) = FRAME_TAB_BAR_LINES (f) *
FRAME_LINE_HEIGHT (f);
(gdb) n
26188 unit = FRAME_COLUMN_WIDTH (f);
(gdb) n
26189 if (FRAME_CONFIG_SCROLL_BAR_WIDTH (f) > 0)
(gdb) n
26190 FRAME_CONFIG_SCROLL_BAR_COLS (f)
(gdb) n
26199 if (FRAME_X_WINDOW (f) != 0 && !FRAME_TOOLTIP_P (f))
(gdb) p f->text_height
$9 = 1044
(gdb) xint
$10 = 261
(gdb) n
26200 adjust_frame_size
(gdb) n
26205 if (FRAME_XIC (f)
(gdb) p f->text_height
$11 = 1008
(gdb) xint
$12 = 252
(gdb) c
Continuing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Wed, 21 Dec 2022 01:16:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 52493 <at> debbugs.gnu.org (full text, mbox):
Hi Eli,
On 17/12/2021 10:38, Eli Zaretskii wrote:
>> From: Lars Ingebrigtsen<larsi <at> gnus.org>
>> Cc: Dmitry Gutov<dgutov <at> yandex.ru>, martin rudalics<rudalics <at> gmx.at>,
>> rpluim <at> gmail.com,52493 <at> debbugs.gnu.org
>> Date: Fri, 17 Dec 2021 08:46:58 +0100
>>
>> Eli Zaretskii<eliz <at> gnu.org> writes:
>>
>>> Lars, do we make that kludge unconditionally compiled on all systems?
>> Yes, I think that makes sense.
> I installed the change. Dmitry, please see if the original problem is
> indeed fixed.
>
> I will not close the bug anyway, because of the resizing issue that
> still needs investigating.
BTW, the original problem is back now. I vaguely recall that we
installed the fix, but then backed out of it?
Maybe we should register that info in this bug somehow. Call it a wontfix?
Too bad the recent changes by Gregory didn't improve this scenario.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Wed, 21 Dec 2022 09:23:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 52493 <at> debbugs.gnu.org (full text, mbox):
Do I understand correctly that you see a 108 pixel decrement
> (gdb) p f->text_height
> $7 = 1116
...
> (gdb) p f->text_height
> $11 = 1008
each time you evaluate
(set-face-attribute 'default nil :height 110 :weight 'medium :family "Inconsolata")
Does the problem also happen with 'frame-inhibit-implied-resize'
non-nil?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Wed, 21 Dec 2022 09:39:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 52493 <at> debbugs.gnu.org (full text, mbox):
>
> Too bad the recent changes by Gregory didn't improve this scenario.
>
Which scenario? If I put
(set-face-attribute 'default nil :height 110 :font "Inconsolata_dz")
in a init file, everything works as I'd expect it to work.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Wed, 21 Dec 2022 12:13:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 21 Dec 2022 03:14:54 +0200
> Cc: rudalics <at> gmx.at, rpluim <at> gmail.com, 52493 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
>
> On 17/12/2021 10:38, Eli Zaretskii wrote:
> >> From: Lars Ingebrigtsen<larsi <at> gnus.org>
> >> Cc: Dmitry Gutov<dgutov <at> yandex.ru>, martin rudalics<rudalics <at> gmx.at>,
> >> rpluim <at> gmail.com,52493 <at> debbugs.gnu.org
> >> Date: Fri, 17 Dec 2021 08:46:58 +0100
> >>
> >> Eli Zaretskii<eliz <at> gnu.org> writes:
> >>
> >>> Lars, do we make that kludge unconditionally compiled on all systems?
> >> Yes, I think that makes sense.
> > I installed the change. Dmitry, please see if the original problem is
> > indeed fixed.
> >
> > I will not close the bug anyway, because of the resizing issue that
> > still needs investigating.
>
> BTW, the original problem is back now. I vaguely recall that we
> installed the fix, but then backed out of it?
Yes, because it caused trouble. See
https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg01643.html
> Maybe we should register that info in this bug somehow. Call it a wontfix?
>
> Too bad the recent changes by Gregory didn't improve this scenario.
I'd actually expect Gregory's changes to fix this, and explicitly
asked him at the time to test this bug's use case; he said back then
it was fixed. Maybe there's some misunderstanding or fine nuances?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Wed, 21 Dec 2022 12:50:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 21 Dec 2022 09:38:02 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
> rudalics <at> gmx.at, rpluim <at> gmail.com, 52493 <at> debbugs.gnu.org
>
>
> >
> > Too bad the recent changes by Gregory didn't improve this scenario.
> >
>
> Which scenario? If I put
>
> (set-face-attribute 'default nil :height 110 :font "Inconsolata_dz")
>
> in a init file, everything works as I'd expect it to work.
Can you show your results and contrast them with what Dmitry reported
in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52493#11
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Wed, 21 Dec 2022 12:57:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 21/12/2022 11:22, martin rudalics wrote:
> Do I understand correctly that you see a 108 pixel decrement
>
> > (gdb) p f->text_height
> > $7 = 1116
>
> ...
>
> > (gdb) p f->text_height
> > $11 = 1008
>
> each time you evaluate
>
> (set-face-attribute 'default nil :height 110 :weight 'medium :family
> "Inconsolata")
Seems so. Or a two text-line decrease each time anyway.
But to be clear, it's InconsolataLGC here. I don't have the "plain"
Inconsolata installed at the moment.
And :weight can be specified or not. That doesn't seem to matter:
(set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
> Does the problem also happen with 'frame-inhibit-implied-resize'
> non-nil?
It does not.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Wed, 21 Dec 2022 13:41:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 21/12/2022 11:38, Gregory Heytings wrote:
>
>>
>> Too bad the recent changes by Gregory didn't improve this scenario.
>>
>
> Which scenario? If I put
Here are a bunch of scenarios, most of them pretty odd. I was primarily
testing scenario number 2.
> (set-face-attribute 'default nil :height 110 :font "Inconsolata_dz")
>
> in a init file, everything works as I'd expect it to work.
1. If I put this in my init file and start Emacs, during startup it
blinks to a weird font (narrow window, narrow characters), but then
finishes startup with a window that looks reasonable (both the size of
the window and the shape of characters). 'M-x describe-face RET default'
reports "Inconsolata_dz" as family.
2. I start 'emacs -Q' and evaluate (set-face-attribute 'default nil
:height 105 :family "Inconsolata_dz") in *scratch*. I get that
weird-looking font that blinks briefly in scenario 1. 'M-x describe-face
RET default' reports "Ubuntu Condensed" as family.
3. I start from the end of 2. and press 'C-x 5 2'. The new window pops
up with reasonable-looking font and size. 'M-x describe-face' reports
"Inconsolata_dz" as family.
4. I start with 'emacs -Q' and evaluate (set-face-attribute 'default nil
:height 110 :family "Cascadia Mono"). This works fine on the first try
without splitting frames, 'M-x describe-face' reports "Cascadia Mono".
Same with "Inconsolata LGC".
5. I start my regular init script with (set-face-attribute 'default nil
:height 105 :family "Inconsolata LGC") in it. Then in scratch evaluate
(set-face-attribute 'default nil :height 105 :family "Inconsolata_dz").
I get another funny-looking font. 'M-x describe-face' says it's "Purisa".
6. I start with 'emacs -Q' and evaluate (set-face-attribute 'default nil
:height 110 :family "Cascadia Mono") there. Works as expected. Then I
evaluate (set-face-attribute 'default nil :height 105 :family
"Inconsolata_dz") -- the font size changes slightly (downward), but the
face remains the same. 'M-x describe-face' corroborates that.
I think the problems here are:
- Inconsolata_dz only works in frames created later.
- Setting font attributes may result in unpredictable results, they
depend on the previous font spec. Even though the explicit attributes
are all rewritten to new values every time.
- Unknown font families fail silently (switching to something else under
the hood). Perhaps it was also the case before, but it adds to the
confusion.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Wed, 21 Dec 2022 13:44:01 GMT)
Full text and
rfc822 format available.
Message #110 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 21/12/2022 11:22, martin rudalics wrote:
> Do I understand correctly that you see a 108 pixel decrement
>
> > (gdb) p f->text_height
> > $7 = 1116
>
> ...
>
> > (gdb) p f->text_height
> > $11 = 1008
>
> each time you evaluate
>
> (set-face-attribute 'default nil :height 110 :weight 'medium :family
> "Inconsolata")
>
> Does the problem also happen with 'frame-inhibit-implied-resize'
> non-nil?
Sorry, here's some missing info:
I don't have a font called "InconsolataLGC", or maybe not anymore. I
have a font called "Inconsolata LGC", with a space.
Evaluating
(set-face-attribute 'default nil :height 110 :family "Inconsolata LGC")
works okay, it's only evaluating
(set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
creates this effect.
The value of 'height' is also important. E.g. it doesn't happen for 105,
for happens for 110.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Wed, 21 Dec 2022 17:06:01 GMT)
Full text and
rfc822 format available.
Message #113 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> Does the problem also happen with 'frame-inhibit-implied-resize'
>> non-nil?
>
> It does not.
OK. Please apply the attached diff, do a few
(set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
and tell me the contents of *foo*. I'd like to know the size hints we
send to the WM.
Thanks, martin
[Gutov.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Wed, 21 Dec 2022 23:01:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 21/12/2022 19:05, martin rudalics wrote:
> >> Does the problem also happen with 'frame-inhibit-implied-resize'
> >> non-nil?
> >
> > It does not.
>
> OK. Please apply the attached diff, do a few
>
> (set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
>
> and tell me the contents of *foo*. I'd like to know the size hints we
> send to the WM.
Thanks, here you go.
Initially its contents are:
xg_wm_set_size_hint .. line_height .. 36 .. base_height .. 43 ..
height_inc .. 18
xg_wm_set_size_hint .. line_height .. 36 .. base_height .. 84 ..
height_inc .. 18
but after I eval the above (one or many times, doesn't matter), it contains:
xg_wm_set_size_hint .. line_height .. 36 .. base_height .. 43 ..
height_inc .. 18
xg_wm_set_size_hint .. line_height .. 36 .. base_height .. 84 ..
height_inc .. 18
xg_wm_set_size_hint .. line_height .. 45 .. base_height .. 88 ..
height_inc .. 22
xg_wm_set_size_hint .. line_height .. 37 .. base_height .. 84 ..
height_inc .. 18
Its contents are also no different at that "special" height where the
frame stops resizing. Just in case that's important.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Wed, 21 Dec 2022 23:40:01 GMT)
Full text and
rfc822 format available.
Message #119 received at 52493 <at> debbugs.gnu.org (full text, mbox):
>> Which scenario? If I put
>>
>> (set-face-attribute 'default nil :height 110 :font "Inconsolata_dz")
>>
>> in a init file, everything works as I'd expect it to work.
>
> Can you show your results and contrast them with what Dmitry reported in
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52493#11
>
Evaluating
(set-face-attribute 'default nil :height 110 :family "Inconsolata_dz")
(note the ":family") has no effect, IOW the font of the default face is
unchanged. Evaluating
(set-face-attribute 'default nil :height 110 :font "Inconsolata_dz")
(note the ":font") changes the default font to Inconsolata_dz, and
(face-font 'default) returns
"-PfEd-Inconsolata_dz-medium-normal-normal-*-29-*-*-*-m-0-iso10646-1"
The result is the same before the change in bug#59347.
With emacs -Q -fn Inconsolata_dz the font of the default face is
"-PfEd-Inconsolata_dz-medium-normal-normal-*-32-*-*-*-m-0-iso10646-1"
The result is the same before the change in bug#59347.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Wed, 21 Dec 2022 23:40:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 52493 <at> debbugs.gnu.org (full text, mbox):
>
> Here are a bunch of scenarios, most of them pretty odd. I was primarily
> testing scenario number 2.
>
Thanks for your detailed reply.
>> (set-face-attribute 'default nil :height 110 :font "Inconsolata_dz")
>>
>> in a init file, everything works as I'd expect it to work.
>
> 1. If I put this in my init file and start Emacs, during startup it
> blinks to a weird font (narrow window, narrow characters), but then
> finishes startup with a window that looks reasonable (both the size of
> the window and the shape of characters). 'M-x describe-face RET default'
> reports "Inconsolata_dz" as family.
>
Can you please try an init file with only that line, and that exact line?
Note that your original recipe used ":family", where ":font" should be
used (and is used in the call to set-face-attribute above).
>
> 2. I start 'emacs -Q' and evaluate (set-face-attribute 'default nil
> :height 105 :family "Inconsolata_dz") in *scratch*. I get that
> weird-looking font that blinks briefly in scenario 1. 'M-x describe-face
> RET default' reports "Ubuntu Condensed" as family.
>
Again, can you try to evaluate (set-face-attribute 'default nil :height
110 :font "Inconsolata_dz") (with ":font", not ":family") instead, and
tell us what happens?
Can you try your other recipes, using ":font" where you used ":family",
and tell us whether what happens is what you expected?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 22 Dec 2022 07:20:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 21 Dec 2022 23:39:22 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: dgutov <at> yandex.ru, larsi <at> gnus.org, rudalics <at> gmx.at, rpluim <at> gmail.com,
> 52493 <at> debbugs.gnu.org
>
>
> >> Which scenario? If I put
> >>
> >> (set-face-attribute 'default nil :height 110 :font "Inconsolata_dz")
> >>
> >> in a init file, everything works as I'd expect it to work.
> >
> > Can you show your results and contrast them with what Dmitry reported in
> >
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52493#11
> >
>
> Evaluating
>
> (set-face-attribute 'default nil :height 110 :family "Inconsolata_dz")
>
> (note the ":family") has no effect, IOW the font of the default face is
> unchanged. Evaluating
>
> (set-face-attribute 'default nil :height 110 :font "Inconsolata_dz")
>
> (note the ":font") changes the default font to Inconsolata_dz, and
> (face-font 'default) returns
>
> "-PfEd-Inconsolata_dz-medium-normal-normal-*-29-*-*-*-m-0-iso10646-1"
>
> The result is the same before the change in bug#59347.
>
> With emacs -Q -fn Inconsolata_dz the font of the default face is
>
> "-PfEd-Inconsolata_dz-medium-normal-normal-*-32-*-*-*-m-0-iso10646-1"
>
> The result is the same before the change in bug#59347.
So this result from Dmitry:
> >> It's a weird scenario, but evaluating this in 'emacs -Q' will make
> >> characters render more narrowly (and a little shorter) than it did
> >> previously:
> >>
> >> (set-face-attribute 'default nil :height 110 :family "Inconsolata_dz")
> >>
> >> See the attached screenshot with comparison (master is on the left).
> >
> > Indeed, weird. What does the below show?
> >
> > M-: (face-font 'default) RET
> >
> > after you evaluate the above in "emacs -Q"?
>
> "-DAMA-Ubuntu Condensed-regular-normal-normal-*-29-*-*-*-*-0-iso10646-1"
is not reproduced on your system, is that right?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 22 Dec 2022 07:21:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 21 Dec 2022 23:39:34 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
> rudalics <at> gmx.at, rpluim <at> gmail.com, 52493 <at> debbugs.gnu.org
>
> > 2. I start 'emacs -Q' and evaluate (set-face-attribute 'default nil
> > :height 105 :family "Inconsolata_dz") in *scratch*. I get that
> > weird-looking font that blinks briefly in scenario 1. 'M-x describe-face
> > RET default' reports "Ubuntu Condensed" as family.
> >
>
> Again, can you try to evaluate (set-face-attribute 'default nil :height
> 110 :font "Inconsolata_dz") (with ":font", not ":family") instead, and
> tell us what happens?
>
> Can you try your other recipes, using ":font" where you used ":family",
> and tell us whether what happens is what you expected?
What is the significance of using :font instead of :family in these
cases, for the purpose of discussing and investigating this issue?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 22 Dec 2022 10:16:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Initially its contents are:
>
> xg_wm_set_size_hint .. line_height .. 36 .. base_height .. 43 .. height_inc .. 18
> xg_wm_set_size_hint .. line_height .. 36 .. base_height .. 84 .. height_inc .. 18
>
> but after I eval the above (one or many times, doesn't matter), it contains:
>
> xg_wm_set_size_hint .. line_height .. 36 .. base_height .. 43 .. height_inc .. 18
> xg_wm_set_size_hint .. line_height .. 36 .. base_height .. 84 .. height_inc .. 18
> xg_wm_set_size_hint .. line_height .. 45 .. base_height .. 88 .. height_inc .. 22
> xg_wm_set_size_hint .. line_height .. 37 .. base_height .. 84 .. height_inc .. 18
>
> Its contents are also no different at that "special" height where the frame stops resizing. Just in case that's important.
Thanks. Please with the new patch attached eval in *scratch* the first
form
(defun foo-set-face-attribute ()
(foo-it "set-face-attribute")
(set-face-attribute 'default nil :height 110 :family "InconsolataLGC"))
(foo-set-face-attribute)
and then eval the last form a couple of times. This should help us to
discern whether and how 'set-face-attribute' has an effect on the size
hints.
martin
[Gutov.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 22 Dec 2022 20:33:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 22/12/2022 01:39, Gregory Heytings wrote:
>
>>
>> Here are a bunch of scenarios, most of them pretty odd. I was
>> primarily testing scenario number 2.
>>
>
> Thanks for your detailed reply.
>
>>> (set-face-attribute 'default nil :height 110 :font "Inconsolata_dz")
>>>
>>> in a init file, everything works as I'd expect it to work.
>>
>> 1. If I put this in my init file and start Emacs, during startup it
>> blinks to a weird font (narrow window, narrow characters), but then
>> finishes startup with a window that looks reasonable (both the size of
>> the window and the shape of characters). 'M-x describe-face RET
>> default' reports "Inconsolata_dz" as family.
>>
>
> Can you please try an init file with only that line, and that exact
> line? Note that your original recipe used ":family", where ":font"
> should be used (and is used in the call to set-face-attribute above).
With :font, the recipe seems to be working fine. Thanks!
I've always used :family for this purpose in the past.
>> 2. I start 'emacs -Q' and evaluate (set-face-attribute 'default nil
>> :height 105 :family "Inconsolata_dz") in *scratch*. I get that
>> weird-looking font that blinks briefly in scenario 1. 'M-x
>> describe-face RET default' reports "Ubuntu Condensed" as family.
>>
>
> Again, can you try to evaluate (set-face-attribute 'default nil :height
> 110 :font "Inconsolata_dz") (with ":font", not ":family") instead, and
> tell us what happens?
The behavior seems to be as expected: this font is assigned in the
current frame.
> Can you try your other recipes, using ":font" where you used ":family",
> and tell us whether what happens is what you expected?
Almost good, with one problem jumping out, however:
- Evaluate (set-face-attribute 'default nil :height 105 :weight 'regular
:font "Inconsolata LGC"), result:
Family: Inconsolata LGC
Foundry: PfEd
Width: normal
Height: 105
Weight: regular
- Then I evaluate (set-face-attribute 'default nil :height 110 :weight
'semi-light :font "Cascadia Mono"), the result is:
Family: Inconsolata LGC
Foundry: PfEd
Width: normal
Height: 105
Weight: regular
Note the weight. Cascadia Code seems to be thicker than average as a
font, so the weight of the regular font jumps out, and it was easy to
notice.
If I, however, follow (set-face-attribute 'default nil :height 105
:weight 'regular :font "Inconsolata LGC") with (set-face-attribute
'default nil :height 110 :weight 'semi-light :family "Cascadia Mono") --
note :family, the resulting font looks fine, and is described as:
Family: Cascadia Mono
Foundry: SAJA
Width: normal
Height: 109
Weight: semi-light
Starting the session with (set-face-attribute 'default nil :height 110
:weight 'semi-light :font "Cascadia Mono") also has this problem.
However, switching from :family to :font -- (set-face-attribute 'default
nil :height 110 :weight 'semi-light :family "Cascadia Mono") followed by
(set-face-attribute 'default nil :height 110 :weight 'semi-light :font
"Cascadia Mono") -- is a no-op.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 22 Dec 2022 20:40:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 22/12/2022 12:15, martin rudalics wrote:
> Thanks. Please with the new patch attached eval in *scratch* the first
> form
>
> (defun foo-set-face-attribute ()
> (foo-it "set-face-attribute")
> (set-face-attribute 'default nil :height 110 :family "InconsolataLGC"))
>
> (foo-set-face-attribute)
>
> and then eval the last form a couple of times. This should help us to
> discern whether and how 'set-face-attribute' has an effect on the size
> hints.
The contents of the buffer *foo* are below.
I'm not sure if you caught one of my previous messages, however, so I'd
like to repeat:
The problem is easily repeatable in the above scenario. But not if I
change "InconsolataLGC" to "Inconsolata LGC". Then the resizing stops
after the first iteration.
In either case, 'M-x describe-face RET default' shows "Family:
Inconsolata LGC", though. So it's not like "InconsolataLGC" is entirely
unrecognized.
Anyway, here's the log (evaled the form 3 times):
adjust_frame_size .. pixel_height .. 25 .. text_height .. 24
adjust_frame_size .. pixel_height .. 900 .. text_height .. 900
adjust_frame_size .. pixel_height .. 1296 .. text_height .. 1296
adjust_frame_size .. pixel_height .. 1296 .. text_height .. 1296
xg_wm_set_size_hint .. line_height .. 36 .. base_height .. 43 ..
height_inc .. 18
xg_wm_set_size_hint .. line_height .. 36 .. base_height .. 84 ..
height_inc .. 18
set-face-attribute
xg_wm_set_size_hint .. line_height .. 45 .. base_height .. 88 ..
height_inc .. 22
adjust_frame_size .. pixel_height .. 1584 .. text_height .. 1584
xg_wm_set_size_hint .. line_height .. 37 .. base_height .. 84 ..
height_inc .. 18
adjust_frame_size .. pixel_height .. 1260 .. text_height .. 1260
set-face-attribute
adjust_frame_size .. pixel_height .. 1224 .. text_height .. 1224
adjust_frame_size .. pixel_height .. 1188 .. text_height .. 1188
set-face-attribute
adjust_frame_size .. pixel_height .. 1152 .. text_height .. 1152
adjust_frame_size .. pixel_height .. 1116 .. text_height .. 1116
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 23 Dec 2022 09:15:01 GMT)
Full text and
rfc822 format available.
Message #140 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> I'm not sure if you caught one of my previous messages, however, so I'd like to repeat:
>
> The problem is easily repeatable in the above scenario. But not if I change "InconsolataLGC" to "Inconsolata LGC". Then the resizing stops after the first iteration.
>
> In either case, 'M-x describe-face RET default' shows "Family: Inconsolata LGC", though. So it's not like "InconsolataLGC" is entirely unrecognized.
Does it matter? Whatever you do - have the same form evaluated twice in
a row causing a frame resize must be a bug - somewhere.
> Anyway, here's the log (evaled the form 3 times):
>
> adjust_frame_size .. pixel_height .. 25 .. text_height .. 24
> adjust_frame_size .. pixel_height .. 900 .. text_height .. 900
> adjust_frame_size .. pixel_height .. 1296 .. text_height .. 1296
> adjust_frame_size .. pixel_height .. 1296 .. text_height .. 1296
> xg_wm_set_size_hint .. line_height .. 36 .. base_height .. 43 .. height_inc .. 18
> xg_wm_set_size_hint .. line_height .. 36 .. base_height .. 84 .. height_inc .. 18
We start here
> set-face-attribute
> xg_wm_set_size_hint .. line_height .. 45 .. base_height .. 88 .. height_inc .. 22
and come up with a frame line height of 45 pixels and an increment hint
of 22 which means that some scaling (by 2 apparently) is in effect here.
Honestly, I have no idea how this is supposed to work.
> adjust_frame_size .. pixel_height .. 1584 .. text_height .. 1584
> xg_wm_set_size_hint .. line_height .. 37 .. base_height .. 84 .. height_inc .. 18
Here we ask for the same (due to rounding) increment ...
> adjust_frame_size .. pixel_height .. 1260 .. text_height .. 1260
> set-face-attribute
> adjust_frame_size .. pixel_height .. 1224 .. text_height .. 1224
> adjust_frame_size .. pixel_height .. 1188 .. text_height .. 1188
> set-face-attribute
> adjust_frame_size .. pixel_height .. 1152 .. text_height .. 1152
> adjust_frame_size .. pixel_height .. 1116 .. text_height .. 1116
... but then we do not set hints any more so it seems that we do all the
shrinking ourselves - just how can we shrink and not send size hints at
the same time is yet a mystery to me.
Please run again with the new patch but also evaluate
(setq frame-size-history '(100))
Then perform some 'set-face-attribute' calls, evaluate
(frame--size-history)
and get me the contents of both buffers *foo* and *frame-size-history*.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 23 Dec 2022 09:20:01 GMT)
Full text and
rfc822 format available.
Message #143 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Please run again with the new patch but also evaluate
Attaching the "new" patch now.
martin
[Gutov.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 23 Dec 2022 18:49:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 23/12/2022 11:14, martin rudalics wrote:
> > I'm not sure if you caught one of my previous messages, however, so
> I'd like to repeat:
> >
> > The problem is easily repeatable in the above scenario. But not if I
> change "InconsolataLGC" to "Inconsolata LGC". Then the resizing stops
> after the first iteration.
> >
> > In either case, 'M-x describe-face RET default' shows "Family:
> Inconsolata LGC", though. So it's not like "InconsolataLGC" is entirely
> unrecognized.
>
> Does it matter? Whatever you do - have the same form evaluated twice in
> a row causing a frame resize must be a bug - somewhere.
Yep.
I just figured that it might give you ideas as to the cause and/or
affect the priority of having this fixed.
> > Anyway, here's the log (evaled the form 3 times):
> >
> > adjust_frame_size .. pixel_height .. 25 .. text_height .. 24
> > adjust_frame_size .. pixel_height .. 900 .. text_height .. 900
> > adjust_frame_size .. pixel_height .. 1296 .. text_height .. 1296
> > adjust_frame_size .. pixel_height .. 1296 .. text_height .. 1296
> > xg_wm_set_size_hint .. line_height .. 36 .. base_height .. 43 ..
> height_inc .. 18
> > xg_wm_set_size_hint .. line_height .. 36 .. base_height .. 84 ..
> height_inc .. 18
>
> We start here
>
> > set-face-attribute
> > xg_wm_set_size_hint .. line_height .. 45 .. base_height .. 88 ..
> height_inc .. 22
>
> and come up with a frame line height of 45 pixels and an increment hint
> of 22 which means that some scaling (by 2 apparently) is in effect here.
> Honestly, I have no idea how this is supposed to work.
2x scaling, yes (I have a 4K display).
> > adjust_frame_size .. pixel_height .. 1584 .. text_height .. 1584
> > xg_wm_set_size_hint .. line_height .. 37 .. base_height .. 84 ..
> height_inc .. 18
>
> Here we ask for the same (due to rounding) increment ...
>
> > adjust_frame_size .. pixel_height .. 1260 .. text_height .. 1260
> > set-face-attribute
> > adjust_frame_size .. pixel_height .. 1224 .. text_height .. 1224
> > adjust_frame_size .. pixel_height .. 1188 .. text_height .. 1188
> > set-face-attribute
> > adjust_frame_size .. pixel_height .. 1152 .. text_height .. 1152
> > adjust_frame_size .. pixel_height .. 1116 .. text_height .. 1116
>
> ... but then we do not set hints any more so it seems that we do all the
> shrinking ourselves - just how can we shrink and not send size hints at
> the same time is yet a mystery to me.
>
> Please run again with the new patch but also evaluate
>
> (setq frame-size-history '(100))
>
> Then perform some 'set-face-attribute' calls, evaluate
>
> (frame--size-history)
>
> and get me the contents of both buffers *foo* and *frame-size-history*.
Here you go, both attached.
I called set-face-attributes 8 times, might have got a little
over-enthusiastic.
[foo.txt (text/plain, attachment)]
[frame-size-history.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sat, 24 Dec 2022 01:04:01 GMT)
Full text and
rfc822 format available.
Message #149 received at 52493 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> When I evaluate
>>
>> (set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
>>
>> (this variation of the font doesn't have the original problem), the height of the window shrinks, unless the window is maximized.
>
> When a frame is maximized, no implied resizing is done. With
>
> (push 'font frame-inhibit-implied-resize)
>
> a non-maximized frame should also keep its size in your case.
>
>> If I evaluate it multiple times, the height shrinks every time I do
>> that
>
> This might be a rounding error or some misunderstanding wrt what the WM
> (mutter in your case?) thinks our frame size is and what Emacs thinks.
> In x_new_font (in xterm.c) we do
>
> FRAME_COLUMN_WIDTH (f) = font->average_width;
> ...
> FRAME_LINE_HEIGHT (f) = font_ascent + font_descent;
> ...
> adjust_frame_size
> (f, FRAME_COLS (f) * FRAME_COLUMN_WIDTH (f),
> FRAME_LINES (f) * FRAME_LINE_HEIGHT (f), 3, false, Qfont);
>
> which should have the effect that (frame-height) and (frame-width)
> remain unaltered when changing the default font. Apparently, this fails
> in your case.
>
>> (stopping at height 5, when even the minibuffer becomes
>> inaccessible
>
> This is a separate issue I fixed here some time ago. But I don't
> remember whether I pushed it and/or whether it requires additional
> customizations to make it DTRT (it might depend on the ability to drop
> window decorations one by one when a frame is shrunk).
>
>> ).
>
>> If I evaluate
>>
>> (set-face-attribute 'default nil :height 110 :family "Inconsolata_dz")
>>
>> (with your fix applied), it only shrinks twice (from 33 to 29 to 27, as reported by (window-height)). And then stops shrinking on subsequent attempts.
>>
>> Doing the same with InconsolataLGC on the latter build still makes it shrink indefinitely.
>
> Here as above, stepping with GDB through the x_new_font code sketched
> above might help tracking down this issue.
>
> martin
Would someone explain what the problem is, and what has already been
fixed? I cannot gather that information from reading the bug report.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sat, 24 Dec 2022 08:53:01 GMT)
Full text and
rfc822 format available.
Message #152 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Would someone explain what the problem is, and what has already been
> fixed? I cannot gather that information from reading the bug report.
In a nutshell, Dmitry repeatedly evaluates 'set-face-attribute' with the
same arguments and has his frame height decrease by 36 pixels each time
he does that.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sat, 24 Dec 2022 09:28:01 GMT)
Full text and
rfc822 format available.
Message #155 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> I called set-face-attributes 8 times, might have got a little over-enthusiastic.
Thanks. It didn't harm. IIUC the problem is in x_new_font. With the
attached please do a few calls again and post the contents of *foo*.
martin
[Gutov.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sat, 24 Dec 2022 09:40:02 GMT)
Full text and
rfc822 format available.
Message #158 received at 52493 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Would someone explain what the problem is, and what has already been
>> fixed? I cannot gather that information from reading the bug report.
>
> In a nutshell, Dmitry repeatedly evaluates 'set-face-attribute' with the
> same arguments and has his frame height decrease by 36 pixels each time
> he does that.
>
> martin
Right. What exact invocation of `set-face-attribute'?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sat, 24 Dec 2022 10:46:02 GMT)
Full text and
rfc822 format available.
Message #161 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Right. What exact invocation of `set-face-attribute'?
(set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
AFAICT the problem is either with
get_font_ascent_descent (font, &font_ascent, &font_descent);
for that font or in an ensuing size hints base height conflict.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sat, 24 Dec 2022 11:25:02 GMT)
Full text and
rfc822 format available.
Message #164 received at 52493 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Right. What exact invocation of `set-face-attribute'?
>
> (set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
>
> AFAICT the problem is either with
>
> get_font_ascent_descent (font, &font_ascent, &font_descent);
>
> for that font or in an ensuing size hints base height conflict.
>
> martin
I don't have that font, would you please attach it in a reply?
Thanks a lot.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sat, 24 Dec 2022 13:04:01 GMT)
Full text and
rfc822 format available.
Message #167 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 24/12/2022 13:24, Po Lu wrote:
> martin rudalics<rudalics <at> gmx.at> writes:
>
>>> Right. What exact invocation of `set-face-attribute'?
>> (set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
>>
>> AFAICT the problem is either with
>>
>> get_font_ascent_descent (font, &font_ascent, &font_descent);
>>
>> for that font or in an ensuing size hints base height conflict.
>>
>> martin
> I don't have that font, would you please attach it in a reply?
> Thanks a lot.
Here it is.
[InconsolataLGC-Regular.otf (application/vnd.oasis.opendocument.formula-template, attachment)]
[InconsolataLGC-Bold.otf (application/vnd.oasis.opendocument.formula-template, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sat, 24 Dec 2022 13:39:02 GMT)
Full text and
rfc822 format available.
Message #170 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 24/12/2022 11:27, martin rudalics wrote:
> > I called set-face-attributes 8 times, might have got a little
> over-enthusiastic.
>
> Thanks. It didn't harm. IIUC the problem is in x_new_font. With the
> attached please do a few calls again and post the contents of *foo*.
Here you go:
x_new_font .. ascent .. 30 .. descent .. 6 .. line_height .. 36
adjust_frame_size .. pixel_height .. 25 .. text_height .. 24
adjust_frame_size .. pixel_height .. 900 .. text_height .. 900
adjust_frame_size .. pixel_height .. 1296 .. text_height .. 1296
adjust_frame_size .. pixel_height .. 1296 .. text_height .. 1296
xg_wm_set_size_hint .. line_height & scale .. 36 .. 2 .. base_height ..
43 .. height_inc .. 18
xg_wm_set_size_hint .. line_height & scale .. 36 .. 2 .. base_height ..
84 .. height_inc .. 18
x_new_font .. ascent .. 37 .. descent .. 8 .. line_height .. 45
xg_wm_set_size_hint .. line_height & scale .. 45 .. 2 .. base_height ..
88 .. height_inc .. 22
adjust_frame_size .. pixel_height .. 1584 .. text_height .. 1584
x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
xg_wm_set_size_hint .. line_height & scale .. 37 .. 2 .. base_height ..
84 .. height_inc .. 18
adjust_frame_size .. pixel_height .. 1260 .. text_height .. 1260
x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
adjust_frame_size .. pixel_height .. 1224 .. text_height .. 1224
x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
adjust_frame_size .. pixel_height .. 1188 .. text_height .. 1188
x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
adjust_frame_size .. pixel_height .. 1152 .. text_height .. 1152
x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
adjust_frame_size .. pixel_height .. 1116 .. text_height .. 1116
x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
adjust_frame_size .. pixel_height .. 1080 .. text_height .. 1080
x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
adjust_frame_size .. pixel_height .. 1044 .. text_height .. 1044
x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
adjust_frame_size .. pixel_height .. 1008 .. text_height .. 1008
x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
adjust_frame_size .. pixel_height .. 972 .. text_height .. 972
x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
adjust_frame_size .. pixel_height .. 936 .. text_height .. 936
x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
adjust_frame_size .. pixel_height .. 900 .. text_height .. 900
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sun, 25 Dec 2022 10:22:01 GMT)
Full text and
rfc822 format available.
Message #173 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> adjust_frame_size .. pixel_height .. 1260 .. text_height .. 1260
> x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
> adjust_frame_size .. pixel_height .. 1224 .. text_height .. 1224
> x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
> adjust_frame_size .. pixel_height .. 1188 .. text_height .. 1188
> x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
FWIW I can't see anything wrong with the font. From the earlier
xg_frame_set_char_size, visible, PS=1408x1188, XS=1408x1184
ConfigureNotify, PS=1408x1188, XS=1408x1152
xg_frame_resized, changed, PS=1408x1188, XS=1408x1152
I can only tell that, for example, we want to resize the frame from
1408x1188 to 1408x1184 pixels but the ensuing ConfigureNotify tells us
that mutter has sized us down to 1408x1152 pixels (that's the -36
increment you see every time) and we comply. I have no idea why that
should happen - after all 1184 is (* 37 32) so it's rather the earlier
1188 that's wrong here. But we've also set the base height to 84 and a
height increment of 18 which are both suspicious.
Anyway: I attach a new patch to shed more light on this. Three
'set-face-attribute' iterations suffice, post me the contents of *foo*
please.
Thanks, martin
[Gutov.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sun, 25 Dec 2022 13:03:02 GMT)
Full text and
rfc822 format available.
Message #176 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 25/12/2022 12:21, martin rudalics wrote:
> FWIW I can't see anything wrong with the font. From the earlier
>
> xg_frame_set_char_size, visible, PS=1408x1188, XS=1408x1184
> ConfigureNotify, PS=1408x1188, XS=1408x1152
> xg_frame_resized, changed, PS=1408x1188, XS=1408x1152
>
> I can only tell that, for example, we want to resize the frame from
> 1408x1188 to 1408x1184 pixels but the ensuing ConfigureNotify tells us
> that mutter has sized us down to 1408x1152 pixels (that's the -36
> increment you see every time) and we comply. I have no idea why that
> should happen - after all 1184 is (* 37 32) so it's rather the earlier
> 1188 that's wrong here. But we've also set the base height to 84 and a
> height increment of 18 which are both suspicious.
>
> Anyway: I attach a new patch to shed more light on this. Three
> 'set-face-attribute' iterations suffice, post me the contents of *foo*
> please.
Done, here:
x_new_font .. ascent .. 30 .. descent .. 6 .. line_height .. 36
adjust_frame_size_1 .. new_text_height .. 24 .. old_native_height .. 25
.. text_to_pixel .. 25
top_margin .. 1 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 2
adjust_frame_size_2 .. pixel_height .. 25 .. text_height .. 24
adjust_frame_size_1 .. new_text_height .. 900 .. old_native_height .. 25
.. text_to_pixel .. 900
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 72
adjust_frame_size_2 .. pixel_height .. 900 .. text_height .. 900
adjust_frame_size_1 .. new_text_height .. 1296 .. old_native_height ..
900 .. text_to_pixel .. 1296
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 72
adjust_frame_size_2 .. pixel_height .. 1296 .. text_height .. 1296
adjust_frame_size_1 .. new_text_height .. 1296 .. old_native_height ..
1296 .. text_to_pixel .. 1296
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 180
adjust_frame_size_2 .. pixel_height .. 1296 .. text_height .. 1296
adjust_frame_size_1 .. new_text_height .. 1296 .. old_native_height ..
1296 .. text_to_pixel .. 1296
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 180
adjust_frame_size_1 .. new_text_height .. 1296 .. old_native_height ..
1296 .. text_to_pixel .. 1296
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 180
adjust_frame_size_1 .. new_text_height .. 1296 .. old_native_height ..
1296 .. text_to_pixel .. 1296
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 180
adjust_frame_size_1 .. new_text_height .. 1296 .. old_native_height ..
1296 .. text_to_pixel .. 1296
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 72
adjust_frame_size_1 .. new_text_height .. 1296 .. old_native_height ..
1296 .. text_to_pixel .. 1296
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 180
adjust_frame_size_1 .. new_text_height .. 1296 .. old_native_height ..
1296 .. text_to_pixel .. 1296
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 72
xg_wm_set_size_hint .. line_height & scale .. 36 .. 2 .. base_height ..
43 .. height_inc .. 18
adjust_frame_size_1 .. new_text_height .. 1296 .. old_native_height ..
1296 .. text_to_pixel .. 1296
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 72
adjust_frame_size_1 .. new_text_height .. 1296 .. old_native_height ..
1296 .. text_to_pixel .. 1296
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 180
xg_wm_set_size_hint .. line_height & scale .. 36 .. 2 .. base_height ..
84 .. height_inc .. 18
x_new_font .. ascent .. 37 .. descent .. 8 .. line_height .. 45
adjust_frame_size_1 .. new_text_height .. 1620 .. old_native_height ..
1296 .. text_to_pixel .. 1620
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 225
xg_wm_set_size_hint .. line_height & scale .. 45 .. 2 .. base_height ..
88 .. height_inc .. 22
adjust_frame_size_1 .. new_text_height .. 1584 .. old_native_height ..
1296 .. text_to_pixel .. 1584
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 90
adjust_frame_size_2 .. pixel_height .. 1584 .. text_height .. 1584
x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
adjust_frame_size_1 .. new_text_height .. 1295 .. old_native_height ..
1584 .. text_to_pixel .. 1295
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 185
xg_wm_set_size_hint .. line_height & scale .. 37 .. 2 .. base_height ..
84 .. height_inc .. 18
adjust_frame_size_1 .. new_text_height .. 1260 .. old_native_height ..
1584 .. text_to_pixel .. 1260
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 74
adjust_frame_size_2 .. pixel_height .. 1260 .. text_height .. 1260
x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
adjust_frame_size_1 .. new_text_height .. 1258 .. old_native_height ..
1260 .. text_to_pixel .. 1258
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 185
adjust_frame_size_1 .. new_text_height .. 1224 .. old_native_height ..
1260 .. text_to_pixel .. 1224
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 74
adjust_frame_size_2 .. pixel_height .. 1224 .. text_height .. 1224
x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
adjust_frame_size_1 .. new_text_height .. 1221 .. old_native_height ..
1224 .. text_to_pixel .. 1221
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 185
adjust_frame_size_1 .. new_text_height .. 1188 .. old_native_height ..
1224 .. text_to_pixel .. 1188
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 74
adjust_frame_size_2 .. pixel_height .. 1188 .. text_height .. 1188
x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
adjust_frame_size_1 .. new_text_height .. 1184 .. old_native_height ..
1188 .. text_to_pixel .. 1184
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 185
adjust_frame_size_1 .. new_text_height .. 1152 .. old_native_height ..
1188 .. text_to_pixel .. 1152
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 74
adjust_frame_size_2 .. pixel_height .. 1152 .. text_height .. 1152
x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
adjust_frame_size_1 .. new_text_height .. 1147 .. old_native_height ..
1152 .. text_to_pixel .. 1147
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 185
adjust_frame_size_1 .. new_text_height .. 1116 .. old_native_height ..
1152 .. text_to_pixel .. 1116
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 74
adjust_frame_size_2 .. pixel_height .. 1116 .. text_height .. 1116
adjust_frame_size_1 .. new_text_height .. 1116 .. old_native_height ..
1116 .. text_to_pixel .. 1116
top_margin .. 0 .. scroll_bar .. 0 .. 2*border .. 0 ..
min_inner_height .. 185
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sun, 25 Dec 2022 16:09:01 GMT)
Full text and
rfc822 format available.
Message #179 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Done, here:
Still tapping in the dark. One other possibility I see is that we
somehow mess things up with the menu or tool bar. Next patch, three
iterations suffice, please post contents of *foo*.
Thanks, martin
[Gutov.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sun, 25 Dec 2022 16:53:01 GMT)
Full text and
rfc822 format available.
Message #182 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 25/12/2022 18:07, martin rudalics wrote:
> > Done, here:
>
> Still tapping in the dark. One other possibility I see is that we
> somehow mess things up with the menu or tool bar. Next patch, three
> iterations suffice, please post contents of *foo*.
Aaand, here you go:
x_new_font .. ascent .. 30 .. descent .. 6 .. line_height .. 36
adjust_frame_size .. old pixels/lines .. 25 .. 25 .. new pixels/lines ..
25 .. 24
adjust_frame_size .. old pixels/lines .. 25 .. 25 .. new pixels/lines ..
900 .. 25
adjust_frame_size .. old pixels/lines .. 900 .. 25 .. new pixels/lines
.. 1296 .. 36
adjust_frame_size .. old pixels/lines .. 1296 .. 36 .. new pixels/lines
.. 1296 .. 36
xg_wm_set_size_hint .. line_height & scale .. 36 .. 2 .. base_height ..
25 .. height_inc .. 18
menubar_height .. 50 .. toolbar_height .. 0
xg_wm_set_size_hint .. line_height & scale .. 36 .. 2 .. base_height ..
66 .. height_inc .. 18
menubar_height .. 50 .. toolbar_height .. 82
x_new_font .. ascent .. 37 .. descent .. 8 .. line_height .. 45
xg_wm_set_size_hint .. line_height & scale .. 45 .. 2 .. base_height ..
66 .. height_inc .. 22
menubar_height .. 50 .. toolbar_height .. 82
adjust_frame_size .. old pixels/lines .. 1296 .. 36 .. new pixels/lines
.. 1584 .. 35
x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
xg_wm_set_size_hint .. line_height & scale .. 37 .. 2 .. base_height ..
66 .. height_inc .. 18
menubar_height .. 50 .. toolbar_height .. 82
adjust_frame_size .. old pixels/lines .. 1584 .. 35 .. new pixels/lines
.. 1260 .. 34
x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
adjust_frame_size .. old pixels/lines .. 1260 .. 34 .. new pixels/lines
.. 1224 .. 33
x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
adjust_frame_size .. old pixels/lines .. 1224 .. 33 .. new pixels/lines
.. 1188 .. 32
x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
adjust_frame_size .. old pixels/lines .. 1188 .. 32 .. new pixels/lines
.. 1152 .. 31
x_new_font .. ascent .. 31 .. descent .. 6 .. line_height .. 37
adjust_frame_size .. old pixels/lines .. 1152 .. 31 .. new pixels/lines
.. 1116 .. 30
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sun, 25 Dec 2022 22:43:02 GMT)
Full text and
rfc822 format available.
Message #185 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> So this result from Dmitry:
>
>>>> It's a weird scenario, but evaluating this in 'emacs -Q' will make
>>>> characters render more narrowly (and a little shorter) than it did
>>>> previously:
>>>>
>>>> (set-face-attribute 'default nil :height 110 :family "Inconsolata_dz")
>>>>
>>>> See the attached screenshot with comparison (master is on the left).
>>>
>>> Indeed, weird. What does the below show?
>>>
>>> M-: (face-font 'default) RET
>>>
>>> after you evaluate the above in "emacs -Q"?
>>
>> "-DAMA-Ubuntu Condensed-regular-normal-normal-*-29-*-*-*-*-0-iso10646-1"
>
> is not reproduced on your system, is that right?
>
Correct. But I don't have the Ubuntu Condensed font installed, so it's
not surprising that this result cannot be reproduced exactly. It does not
reproduce approximately either, in the sense that (set-face-attribute
'default nil :height 110 :family "Inconsolata_dz") does not change the
font at all, not even temporarily.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sun, 25 Dec 2022 22:43:02 GMT)
Full text and
rfc822 format available.
Message #188 received at 52493 <at> debbugs.gnu.org (full text, mbox):
>>> 2. I start 'emacs -Q' and evaluate (set-face-attribute 'default nil
>>> :height 105 :family "Inconsolata_dz") in *scratch*. I get that
>>> weird-looking font that blinks briefly in scenario 1. 'M-x
>>> describe-face RET default' reports "Ubuntu Condensed" as family.
>>
>> Again, can you try to evaluate (set-face-attribute 'default nil :height
>> 110 :font "Inconsolata_dz") (with ":font", not ":family") instead, and
>> tell us what happens?
>>
>> Can you try your other recipes, using ":font" where you used ":family",
>> and tell us whether what happens is what you expected?
>
> What is the significance of using :font instead of :family in these
> cases, for the purpose of discussing and investigating this issue?
>
The two reasons are:
1. IME passing an font name in the :font attribute gives in general better
results than passing a font name in the :family attribute. (And Dmitry
confirmed that the problem he was facing was mostly solved with that
change.)
2. Dmitry's specific recipe, which worked with Emacs 28, cannot work
anymore with Emacs 29 because of dae3c4e89b.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sun, 25 Dec 2022 22:43:03 GMT)
Full text and
rfc822 format available.
Message #191 received at 52493 <at> debbugs.gnu.org (full text, mbox):
>
> Almost good, with one problem jumping out, however:
>
> - Evaluate (set-face-attribute 'default nil :height 105 :weight 'regular
> :font "Inconsolata LGC"), result:
>
> Family: Inconsolata LGC
> Foundry: PfEd
> Width: normal
> Height: 105
> Weight: regular
>
> - Then I evaluate (set-face-attribute 'default nil :height 110 :weight
> 'semi-light :font "Cascadia Mono"), the result is:
>
> Family: Inconsolata LGC
> Foundry: PfEd
> Width: normal
> Height: 105
> Weight: regular
>
You mean
Family: Cascadia Mono
Foundry: SAJA
Width: normal
Height: 105
Weight: regular
right? That is, the :weight 'semi-light attribute is not obeyed? I
observe the same behavior with Emacs 26-27-28, so at least it's not a
regression.
>
> If I, however, follow (set-face-attribute 'default nil :height 105
> :weight 'regular :font "Inconsolata LGC") with (set-face-attribute
> 'default nil :height 110 :weight 'semi-light :family "Cascadia Mono") --
> note :family, the resulting font looks fine, and is described as:
>
> Family: Cascadia Mono
> Foundry: SAJA
> Width: normal
> Height: 109
> Weight: semi-light
>
Indeed. A better way to do what you want is to move the :font attribute
to the front:
(set-face-attribute 'default nil :font "Inconsolata LGC" :height 105 :weight 'regular)
(set-face-attribute 'default nil :font "Cascadia Mono" :height 105 :weight 'semi-light)
>
> Starting the session with (set-face-attribute 'default nil :height 110
> :weight 'semi-light :font "Cascadia Mono") also has this problem.
>
Likewise: move the :font attribute to the front and it will work.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sun, 25 Dec 2022 22:53:01 GMT)
Full text and
rfc822 format available.
Message #194 received at 52493 <at> debbugs.gnu.org (full text, mbox):
>
> This is one additional piece of misbehavior (perhaps unrelated) that
> really caught my eye during these tests:
>
> When I evaluate
>
> (set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
>
> (this variation of the font doesn't have the original problem), the
> height of the window shrinks, unless the window is maximized.
>
FWIW, I cannot reproduce this part of your bug report here.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Mon, 26 Dec 2022 00:47:02 GMT)
Full text and
rfc822 format available.
Message #197 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
By the way, I did not realize that the docstring of 'set-face-attribute'
says nothing about the evaluation order of its arguments. I suggest the
attached patch.
Eli, is this okay for the release branch?
[Clarify-evaluation-order-in-set-face-attribute.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Mon, 26 Dec 2022 09:11:01 GMT)
Full text and
rfc822 format available.
Message #200 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Aaand, here you go:
So far I'm pretty sure that we have some rounding problem here - maybe
due to scaling. The last version of my patch is attached, please use
that for further experiments.
Now first do what you have done so far (three iterations) and post the
results.
Next, if possible, try to turn scaling off, do the same experiments and
post the results.
Finally, with scaling turned on again, start Emacs with
--eval "(setq frame-resize-pixelwise t)"
do the same experiments and post the results.
Thanks, martin
[Gutov.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Mon, 26 Dec 2022 12:21:02 GMT)
Full text and
rfc822 format available.
Message #203 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 25 Dec 2022 22:42:40 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: dgutov <at> yandex.ru, larsi <at> gnus.org, rudalics <at> gmx.at, rpluim <at> gmail.com,
> 52493 <at> debbugs.gnu.org
>
> > What is the significance of using :font instead of :family in these
> > cases, for the purpose of discussing and investigating this issue?
> >
>
> The two reasons are:
>
> 1. IME passing an font name in the :font attribute gives in general better
> results than passing a font name in the :family attribute. (And Dmitry
> confirmed that the problem he was facing was mostly solved with that
> change.)
It is strange, because if the family is simply the name of the font,
it should be interpreted the same, because what else could family mean
in that case?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Mon, 26 Dec 2022 12:26:01 GMT)
Full text and
rfc822 format available.
Message #206 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 26 Dec 2022 00:46:30 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: rudalics <at> gmx.at, Eli Zaretskii <eliz <at> gnu.org>, 52493 <at> debbugs.gnu.org,
> Lars Ingebrigtsen <larsi <at> gnus.org>, rpluim <at> gmail.com
>
> --- a/lisp/faces.el
> +++ b/lisp/faces.el
> @@ -690,6 +690,17 @@ set-face-attribute
> what the FACE's face spec says, call this function with FRAME set to
> t and the ATTRIBUTE's value set to `unspecified'.
>
> +Note that the ATTRIBUTE VALUE pairs are evaluated in the order
> +they are specified, except the `:family' and `:foundry'
> +attributes which are evaluated first. This means both that only
> +the last VALUE of a given ATTRIBUTE will be used, and that in
> +some cases a different order will give different results. For
> +example, when `:weight' is placed before `:font', the weight
> +value is applied to the current font of the face and might be
> +rounded to the closest available weight of that font, whereas
> +when `:font' is placed before `:weight' the weight value is
> +applied to the specified font.
The text is OK, but please put this in the manual, not in the doc
string. If we want something to this effect in the doc string, let's
just have the first sentence there, and then a reference to the
manual.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Mon, 26 Dec 2022 14:06:01 GMT)
Full text and
rfc822 format available.
Message #209 received at 52493 <at> debbugs.gnu.org (full text, mbox):
>> IME passing an font name in the :font attribute gives in general better
>> results than passing a font name in the :family attribute. (And Dmitry
>> confirmed that the problem he was facing was mostly solved with that
>> change.)
>
> It is strange, because if the family is simply the name of the font, it
> should be interpreted the same, because what else could family mean in
> that case?
>
In theory, yes, but in practice the code paths are different in both
cases. The :font attribute gets a special treatment in
Finternal_set_lisp_face_attribute, which is more "direct" than the
treatment of the :family attribute, and (again IME) gives better results.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Mon, 26 Dec 2022 15:49:01 GMT)
Full text and
rfc822 format available.
Message #212 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 26/12/2022 02:46, Gregory Heytings wrote:
> By the way, I did not realize that the docstring of 'set-face-attribute'
> says nothing about the evaluation order of its arguments. I suggest the
> attached patch.
Are we sure that having order-dependent behavior is a good idea?
Since all args are available at the time of evaluation, wouldn't it be
better to handle :font and/or :family before all the others?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Mon, 26 Dec 2022 16:20:01 GMT)
Full text and
rfc822 format available.
Message #215 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> By the way, I did not realize that the docstring of
>> 'set-face-attribute' says nothing about the evaluation order of its
>> arguments. I suggest the attached patch.
>
> Are we sure that having order-dependent behavior is a good idea?
>
I did not design that function, that's how it works. But given how
intricate the face machinery is, I'm not sure it's possible to do much
better.
>
> Since all args are available at the time of evaluation, wouldn't it be
> better to handle :font and/or :family before all the others?
>
You may have seen in the attached patch that :family is indeed handled
before all other attributes, but not :font.
Can you please confirm that the recipes you sent are working as expected
when you place the :font attribute before all other attributes?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Tue, 27 Dec 2022 02:00:01 GMT)
Full text and
rfc822 format available.
Message #218 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 26/12/2022 00:42, Gregory Heytings wrote:
>>
>> Almost good, with one problem jumping out, however:
>>
>> - Evaluate (set-face-attribute 'default nil :height 105 :weight
>> 'regular :font "Inconsolata LGC"), result:
>>
>> Family: Inconsolata LGC
>> Foundry: PfEd
>> Width: normal
>> Height: 105
>> Weight: regular
>>
>> - Then I evaluate (set-face-attribute 'default nil :height 110 :weight
>> 'semi-light :font "Cascadia Mono"), the result is:
>>
>> Family: Inconsolata LGC
>> Foundry: PfEd
>> Width: normal
>> Height: 105
>> Weight: regular
>>
>
> You mean
>
> Family: Cascadia Mono
> Foundry: SAJA
> Width: normal
> Height: 105
> Weight: regular
>
> right? That is, the :weight 'semi-light attribute is not obeyed? I
> observe the same behavior with Emacs 26-27-28, so at least it's not a
> regression.
It's not there if I use :family, though. So if from now on we recommend
people use :font where whey might have used :family in the past, this
might be perceived as a regression.
>> Starting the session with (set-face-attribute 'default nil :height 110
>> :weight 'semi-light :font "Cascadia Mono") also has this problem.
>>
>
> Likewise: move the :font attribute to the front and it will work.
Thanks, that works fine.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Tue, 27 Dec 2022 02:05:01 GMT)
Full text and
rfc822 format available.
Message #221 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 26/12/2022 18:19, Gregory Heytings wrote:
>
>>> By the way, I did not realize that the docstring of
>>> 'set-face-attribute' says nothing about the evaluation order of its
>>> arguments. I suggest the attached patch.
>>
>> Are we sure that having order-dependent behavior is a good idea?
>>
>
> I did not design that function, that's how it works. But given how
> intricate the face machinery is, I'm not sure it's possible to do much
> better.
It does feel a little odd, though. Could you explain why :family does
get evaluated first, but :font does not? And yet, it's better
recommended to use :font?
I'm not saying these are regressions to be fixed now (Emacs 29 is too
near), but maybe a better design is possible and not too difficult to
transition to later.
>> Since all args are available at the time of evaluation, wouldn't it be
>> better to handle :font and/or :family before all the others?
>>
>
> You may have seen in the attached patch that :family is indeed handled
> before all other attributes, but not :font.
>
> Can you please confirm that the recipes you sent are working as expected
> when you place the :font attribute before all other attributes?
They seem to, thank you.
Except for the frame-height-shrinking one, but that's a separate story.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Tue, 27 Dec 2022 23:17:02 GMT)
Full text and
rfc822 format available.
Message #224 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 26/12/2022 11:10, martin rudalics wrote:
> > Aaand, here you go:
>
> So far I'm pretty sure that we have some rounding problem here - maybe
> due to scaling. The last version of my patch is attached, please use
> that for further experiments.
>
> Now first do what you have done so far (three iterations) and post the
> results.
>
> Next, if possible, try to turn scaling off, do the same experiments and
> post the results.
>
> Finally, with scaling turned on again, start Emacs with
>
> --eval "(setq frame-resize-pixelwise t)"
>
> do the same experiments and post the results.
Here you go, three attachments.
As you previously guessed, the effect didn't show up when the scaling
was off, or when resize-pixelwise was enabled.
[foo-resize-pixelwise.txt (text/plain, attachment)]
[foo-without-scaling.txt (text/plain, attachment)]
[foo-with-scaling.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Wed, 28 Dec 2022 10:09:02 GMT)
Full text and
rfc822 format available.
Message #227 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Here you go, three attachments.
Thank you, they now contain all we need.
> As you previously guessed, the effect didn't show up when the scaling was off, or when resize-pixelwise was enabled.
In both cases we don't scale. Scaling introduces a rounding effect
mutter apparently doesn't like. Take, for example, these lines of
foo-with-scaling.txt produced when we set a new font (actually the first
line belongs to the previous request and is here only to show that we
start with a frame of 35 lines):
adjust_frame_size .. old pixels/lines .. 1296 .. 36 .. new pixels/lines .. 1584 .. 35
x_new_font .. line_height .. 37 .. lines .. 35 .. new_text_height .. 1295
xg_wm_set_size_hint .. line_height & scale .. 37 .. 2 .. base_height .. 84 .. height_inc .. 18
menubar_height .. 50 .. toolbar_height .. 82
xg_frame_set_char_size .. old .. 1584 .. arg .. 1295 .. new .. -1
outer .. 713 .. gheight .. 858
xg_frame_resized .. old .. 1584 .. req .. -1 .. con/text .. 1260 .. 1260
adjust_frame_size .. old pixels/lines .. 1584 .. 35 .. new pixels/lines .. 1260 .. 34
The base_height value (84 pixels) we calculate here is the sum of the
line_height value, the menubar_height value and the toolbar_height
values divided by the scale factor:
(/ (+ 37 50 82) 2)
height_inc (18) is the line height divided by the scale factor (/ 37 2).
These size hints have mutter expect us to resize our frame to something
like
(+ base_height (* height_inc N))
for some positive integer N. Now we want to resize the frame to
line_height times lines, that is (* 37 35) yielding 1295 pixels.
But (% (/ 1295 2) 18) is not zero and so mutter declines our request
giving us 1260 pixels text height instead. Apparently, mutter starts
with (/ 1295 2) that is 647, 630 is the next multiple of 18 it finds, so
(* 630 2) is the value it concedes us.
So the height we should ask for with scaling is 1296 instead of 1295.
Please try the attached patch - I can't test it here because I don't
scale. If it doesn't work, please post the contents of *foo* as usual.
Thanks, martin
[x_scale_font.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Wed, 28 Dec 2022 12:32:02 GMT)
Full text and
rfc822 format available.
Message #230 received at 52493 <at> debbugs.gnu.org (full text, mbox):
Hi Martin!
On 28/12/2022 12:08, martin rudalics wrote:
> The base_height value (84 pixels) we calculate here is the sum of the
> line_height value, the menubar_height value and the toolbar_height
> values divided by the scale factor:
>
> (/ (+ 37 50 82) 2)
>
> height_inc (18) is the line height divided by the scale factor (/ 37 2).
>
> These size hints have mutter expect us to resize our frame to something
> like
>
> (+ base_height (* height_inc N))
>
> for some positive integer N. Now we want to resize the frame to
> line_height times lines, that is (* 37 35) yielding 1295 pixels.
>
> But (% (/ 1295 2) 18) is not zero and so mutter declines our request
> giving us 1260 pixels text height instead. Apparently, mutter starts
> with (/ 1295 2) that is 647, 630 is the next multiple of 18 it finds, so
> (* 630 2) is the value it concedes us.
>
> So the height we should ask for with scaling is 1296 instead of 1295.
>
> Please try the attached patch - I can't test it here because I don't
> scale. If it doesn't work, please post the contents of *foo* as usual.
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. Not sure if it's good or bad, so let's go back to the behavior
with '-Q'.
The height stopped shrinking.
The width started growing. :-D
I don't know if *foo* is helpful here yet, but here you go:
adjust_frame_size .. old pixels/lines .. 25 .. 25 .. new pixels/lines ..
25 .. 24
adjust_frame_size .. old pixels/lines .. 25 .. 25 .. new pixels/lines ..
900 .. 25
adjust_frame_size .. old pixels/lines .. 900 .. 25 .. new pixels/lines
.. 1296 .. 36
xg_frame_set_char_size .. old .. 1296 .. arg .. 1296 .. new .. 1296
outer .. 698 .. gheight .. 200
xg_frame_set_char_size .. old .. 1296 .. arg .. 1296 .. new .. 1296
outer .. 673 .. gheight .. 200
xg_frame_resized .. old .. 1296 .. req .. 1296 .. con/text .. 1346 .. 1346
xg_wm_set_size_hint .. line_height & scale .. 36 .. 2 .. base_height ..
43 .. height_inc .. 18
menubar_height .. 50 .. toolbar_height .. 0
xg_frame_resized .. old .. 1296 .. req .. 1346 .. con/text .. 1296 .. 1296
xg_wm_set_size_hint .. line_height & scale .. 36 .. 2 .. base_height ..
84 .. height_inc .. 18
menubar_height .. 50 .. toolbar_height .. 82
xg_frame_set_char_size .. old .. 1296 .. arg .. 1296 .. new .. -1
outer .. 714 .. gheight .. 673
x_new_font .. line_height .. 45 .. lines .. 36 .. new_text_height .. 1620
xg_wm_set_size_hint .. line_height & scale .. 45 .. 2 .. base_height ..
88 .. height_inc .. 22
menubar_height .. 50 .. toolbar_height .. 82
xg_frame_set_char_size .. old .. 1296 .. arg .. 1656 .. new .. -1
outer .. 894 .. gheight .. 714
xg_frame_resized .. old .. 1296 .. req .. -1 .. con/text .. 1628 .. 1628
adjust_frame_size .. old pixels/lines .. 1296 .. 36 .. new pixels/lines
.. 1628 .. 36
x_new_font .. line_height .. 37 .. lines .. 36 .. new_text_height .. 1332
xg_wm_set_size_hint .. line_height & scale .. 37 .. 2 .. base_height ..
84 .. height_inc .. 18
menubar_height .. 50 .. toolbar_height .. 82
xg_frame_set_char_size .. old .. 1628 .. arg .. 1368 .. new .. -1
outer .. 750 .. gheight .. 880
xg_frame_resized .. old .. 1628 .. req .. -1 .. con/text .. 1368 .. 1368
adjust_frame_size .. old pixels/lines .. 1628 .. 36 .. new pixels/lines
.. 1368 .. 36
x_new_font .. line_height .. 37 .. lines .. 36 .. new_text_height .. 1332
xg_frame_set_char_size .. old .. 1368 .. arg .. 1368 .. new .. -1
outer .. 750 .. gheight .. 750
xg_frame_resized .. old .. 1368 .. req .. -1 .. con/text .. 1368 .. 1368
x_new_font .. line_height .. 37 .. lines .. 36 .. new_text_height .. 1332
xg_frame_set_char_size .. old .. 1368 .. arg .. 1368 .. new .. -1
outer .. 750 .. gheight .. 750
xg_frame_resized .. old .. 1368 .. req .. -1 .. con/text .. 1368 .. 1368
x_new_font .. line_height .. 37 .. lines .. 36 .. new_text_height .. 1332
xg_frame_set_char_size .. old .. 1368 .. arg .. 1368 .. new .. -1
outer .. 750 .. gheight .. 750
xg_frame_resized .. old .. 1368 .. req .. -1 .. con/text .. 1368 .. 1368
x_new_font .. line_height .. 37 .. lines .. 36 .. new_text_height .. 1332
xg_frame_set_char_size .. old .. 1368 .. arg .. 1368 .. new .. -1
outer .. 750 .. gheight .. 750
xg_frame_resized .. old .. 1368 .. req .. -1 .. con/text .. 1368 .. 1368
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Wed, 28 Dec 2022 15:20:02 GMT)
Full text and
rfc822 format available.
Message #233 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> That is, the :weight 'semi-light attribute is not obeyed? I observe
>> the same behavior with Emacs 26-27-28, so at least it's not a
>> regression.
>
> It's not there if I use :family, though.
>
Indeed, that's because the :family attribute is evaluated first, and the
:font attribute isn't.
>
> So if from now on we recommend people use :font where they might have
> used :family in the past, this might be perceived as a regression.
>
That's what I would recommend, indeed, but I'm not the one who decides.
The regression would be fixed by adding :font to the attributes that are
evaluated before all others.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Wed, 28 Dec 2022 15:22:02 GMT)
Full text and
rfc822 format available.
Message #236 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> I did not design that function, that's how it works. But given how
>> intricate the face machinery is, I'm not sure it's possible to do much
>> better.
>
> It does feel a little odd, though. Could you explain why :family does
> get evaluated first, but :font does not?
>
I can't explain that, no. If you look at bug#1127, you'll see that moving
the evaluation of :family and :foundry before other attributes was (in
2008) perceived as a workaround. Apparently that worked well enough, and
it's still there in its original form.
IMO it would make sense to move the evaluation of the :font attribute
before other attributes, for the same reason.
Eli, what do you think of the attached patch?
>
> And yet, it's better recommended to use :font?
>
Again, that's why I'd recommend, but it's not the officially recommended
way of doing things (if such a thing exists).
[Evaluate-font-attribute-earlier-in-set-face-attribut.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Wed, 28 Dec 2022 17:02:01 GMT)
Full text and
rfc822 format available.
Message #239 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 28 Dec 2022 15:20:59 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: rudalics <at> gmx.at, Eli Zaretskii <eliz <at> gnu.org>, 52493 <at> debbugs.gnu.org,
> Lars Ingebrigtsen <larsi <at> gnus.org>, rpluim <at> gmail.com
>
> > It does feel a little odd, though. Could you explain why :family does
> > get evaluated first, but :font does not?
> >
>
> I can't explain that, no. If you look at bug#1127, you'll see that moving
> the evaluation of :family and :foundry before other attributes was (in
> 2008) perceived as a workaround. Apparently that worked well enough, and
> it's still there in its original form.
>
> IMO it would make sense to move the evaluation of the :font attribute
> before other attributes, for the same reason.
>
> Eli, what do you think of the attached patch?
If you want to experiment with this on master, I'm okay with trying
that there. But not on the release branch, where I think we currently
have a reasonably good state (famous last words...) and the issue
being discussed here seems quite marginal and obscure to me to risk
destabilizing what we have.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Wed, 28 Dec 2022 17:37:01 GMT)
Full text and
rfc822 format available.
Message #242 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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?
> Not sure if it's good or bad, so let's go back to
> the behavior with '-Q'.
>
> The height stopped shrinking.
>
> The width started growing. :-D
Repeatedly?
> I don't know if *foo* is helpful here yet, but here you go:
Not for the width. But that's another issue. If mutter complains about
the width not conforming to the (+ base_width (* width_inc N)) rule,
then we have already lost when the sum of fringes and scroll bar is not
a multiple of the frame's column width. Which means, you get a "wrong"
size without any scaling and you may be lucky if that scaling does not
propagate during further 'set-face-attribute' calls. Does each setting
of 'set-face-attribute' increase the width or is it just the first one?
Strictly spoken, Emacs is wrong here and mutter is right. But fixing
this is quite involved since we'd have to disentangle those insane
FRAME_TEXT_COLS_TO_PIXEL_WIDTH and FRAME_TEXT_LINES_TO_PIXEL_HEIGHT
macros into xg_frame_set_char_size which would constitute a real pain.
More precisely, we'd have to treat scroll bars, fringes and internal
border like menu and toolbar and count them into the base_width value.
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.
martin
[x_scale_font.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Wed, 28 Dec 2022 22:37:01 GMT)
Full text and
rfc822 format available.
Message #245 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 28/12/2022 19:35, 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).
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.
So it seems like your latest patch doesn't change this behavior in any
significant way. Still either 80 or 84, at random.
> > Not sure if it's good or bad, so let's go back to
> > the behavior with '-Q'.
> >
> > The height stopped shrinking.
> >
> > The width started growing. :-D
>
> Repeatedly?
Yup. Without limit.
> > I don't know if *foo* is helpful here yet, but here you go:
>
> Not for the width. But that's another issue. If mutter complains about
> the width not conforming to the (+ base_width (* width_inc N)) rule,
> then we have already lost when the sum of fringes and scroll bar is not
> a multiple of the frame's column width. Which means, you get a "wrong"
> size without any scaling and you may be lucky if that scaling does not
> propagate during further 'set-face-attribute' calls. Does each setting
> of 'set-face-attribute' increase the width or is it just the first one?
Every one (at certain starting widths), just like it was with the
shrinking of height.
> Strictly spoken, Emacs is wrong here and mutter is right. But fixing
> this is quite involved since we'd have to disentangle those insane
> FRAME_TEXT_COLS_TO_PIXEL_WIDTH and FRAME_TEXT_LINES_TO_PIXEL_HEIGHT
> macros into xg_frame_set_char_size which would constitute a real pain.
> More precisely, we'd have to treat scroll bars, fringes and internal
> border like menu and toolbar and count them into the base_width value.
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")
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.
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 29 Dec 2022 09:07:01 GMT)
Full text and
rfc822 format available.
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 29 Dec 2022 22:30:03 GMT)
Full text and
rfc822 format available.
Message #251 received at 52493 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 29 Dec 2022 22:46:02 GMT)
Full text and
rfc822 format available.
Message #254 received at 52493 <at> debbugs.gnu.org (full text, mbox):
>
> The text is OK, but please put this in the manual, not in the doc
> string. If we want something to this effect in the doc string, let's
> just have the first sentence there, and then a reference to the manual.
>
Now done (d086cd6cf8). I also aligned the documentation of
set-face-attribute in the manual with that of the docstring, with what was
discussed in bug#57499.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 30 Dec 2022 09:52:01 GMT)
Full text and
rfc822 format available.
Message #257 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Oh, BTW, I have menu-bar, scroll-bar and tool-bar all disabled. The fringes should be on, though.
Then try setting the fringes to one 'frame-char-width' each or set them
to zero.
>> 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.
[...]
> If you think it will help, I can still try stepping through the functions you mentioned, but no earlier than tomorrow.
Please do that. 'describe-face' is one thing. What the display engine
thinks of a font might be another.
>> 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 see.
> 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).
It should do that in terms of whatever we ask for in the width and
height increments - after all, those mouse operations are under full
control of the WM. Whatever size the WM gives us, we comply. Take
these two assignments in xg_wm_set_size_hint:
size_hints.width_inc /= scale;
size_hints.height_inc /= scale;
Instead of the "/= scale"s put some assignments with arbitrary constants
there, say
size_hints.width_inc = 51;
size_hints.height_inc = 7;
You should see that mouse dragging will resize the frame by exactly what
you've put there. BTW: Try with these two lines commented out and tell
me whether mouse dragging becomes _perceptibly_ worse. Removing them
could be a substantial relieve in the future.
The problems start after Emacs takes the values it has been told by the
WM and tries to retrofit them into its own lines/columns framework.
When you next ask Emacs programmatically to resize the frame in terms of
the values it stored there, all those rounding and scaling errors that
piled up fire back. Resizing frames is a continuous dialogue between
Emacs and the WM. If one of them refuses to listen to the other, users
will suffer.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 30 Dec 2022 14:48:01 GMT)
Full text and
rfc822 format available.
Message #260 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 29 Dec 2022 22:45:46 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: dgutov <at> yandex.ru, rudalics <at> gmx.at, 52493 <at> debbugs.gnu.org, larsi <at> gnus.org,
> rpluim <at> gmail.com
>
> > The text is OK, but please put this in the manual, not in the doc
> > string. If we want something to this effect in the doc string, let's
> > just have the first sentence there, and then a reference to the manual.
> >
>
> Now done (d086cd6cf8). I also aligned the documentation of
> set-face-attribute in the manual with that of the docstring, with what was
> discussed in bug#57499.
Thanks.
Unfortunately, you also decided to take this opportunity to make
changes to which I explicitly objected in bug#57499. I reverted that
part. Please don't increase my load of work by making changes we
didn't agree to make.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 30 Dec 2022 15:41:02 GMT)
Full text and
rfc822 format available.
Message #263 received at 52493 <at> debbugs.gnu.org (full text, mbox):
>>> The text is OK, but please put this in the manual, not in the doc
>>> string. If we want something to this effect in the doc string, let's
>>> just have the first sentence there, and then a reference to the
>>> manual.
>>
>> Now done (d086cd6cf8). I also aligned the documentation of
>> set-face-attribute in the manual with that of the docstring, with what
>> was discussed in bug#57499.
>
> Thanks.
>
> Unfortunately, you also decided to take this opportunity to make changes
> to which I explicitly objected in bug#57499. I reverted that part.
> Please don't increase my load of work by making changes we didn't agree
> to make.
>
There must be some misunderstanding here. What I did was nothing more
than to align the manual with the docstring, something which was forgotten
in bug#57499. The paragraph you now restored in the manual is similar to
the paragraph you removed from the docstring in 89695bce3e, and the
paragraph you added in 89695bce3e ("When a new frame is created, attribute
values...") means, as far as I understand, the same as the sentence
If @var{frame} is @code{t}, this function sets the default attributes for
newly created frames; they will effectively override the attribute values
specified by @code{defface}.
which is already in the manual.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 30 Dec 2022 16:16:02 GMT)
Full text and
rfc822 format available.
Message #266 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 30 Dec 2022 15:40:02 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: rudalics <at> gmx.at, larsi <at> gnus.org, 52493 <at> debbugs.gnu.org, rpluim <at> gmail.com,
> dgutov <at> yandex.ru
>
> > Unfortunately, you also decided to take this opportunity to make changes
> > to which I explicitly objected in bug#57499. I reverted that part.
> > Please don't increase my load of work by making changes we didn't agree
> > to make.
> >
>
> There must be some misunderstanding here. What I did was nothing more
> than to align the manual with the docstring, something which was forgotten
> in bug#57499. The paragraph you now restored in the manual is similar to
> the paragraph you removed from the docstring in 89695bce3e, and the
> paragraph you added in 89695bce3e ("When a new frame is created, attribute
> values...") means, as far as I understand, the same as the sentence
>
> If @var{frame} is @code{t}, this function sets the default attributes for
> newly created frames; they will effectively override the attribute values
> specified by @code{defface}.
>
> which is already in the manual.
Yes. That was the compromise we reached back then, and I want it to
stay that way.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 30 Dec 2022 16:28:01 GMT)
Full text and
rfc822 format available.
Message #269 received at 52493 <at> debbugs.gnu.org (full text, mbox):
>
> Yes. That was the compromise we reached back then, and I want it to
> stay that way.
>
Sorry, I don't understand what you mean. Do you mean that the compromise
was to remove the paragraph your removed in 89695bce3e from the docstring,
but not from the manual?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 30 Dec 2022 17:03:02 GMT)
Full text and
rfc822 format available.
Message #272 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 30 Dec 2022 16:27:04 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: rudalics <at> gmx.at, larsi <at> gnus.org, 52493 <at> debbugs.gnu.org, rpluim <at> gmail.com,
> dgutov <at> yandex.ru
>
> > Yes. That was the compromise we reached back then, and I want it to
> > stay that way.
>
> Sorry, I don't understand what you mean. Do you mean that the compromise
> was to remove the paragraph your removed in 89695bce3e from the docstring,
> but not from the manual?
Yes. See
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57499#100
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 30 Dec 2022 17:29:01 GMT)
Full text and
rfc822 format available.
Message #275 received at 52493 <at> debbugs.gnu.org (full text, mbox):
>>> Yes. That was the compromise we reached back then, and I want it to
>>> stay that way.
>>
>> Sorry, I don't understand what you mean. Do you mean that the
>> compromise was to remove the paragraph your removed in 89695bce3e from
>> the docstring, but not from the manual?
>
> Yes. See
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57499#100
>
Okay, that's not what I understood (and TBH that's still not what I
understand now), but I don't think it's useful to continue this
discussion. Sorry for the additional work.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sat, 31 Dec 2022 19:02:01 GMT)
Full text and
rfc822 format available.
Message #278 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I've rewritten the output routines so they catch the width changes but
didn't change anything else. The output in *foo* should be almost
self-explanatory now but see first one I ran with emacs -Q and the
following four evaluations
(set-face-attribute 'default nil :height 120 :family "DejaVu Sans Mono")
(set-face-attribute 'default nil :height 140 :family "DejaVu Sans Mono")
(set-face-attribute 'default nil :height 130 :family "DejaVu Sans Mono")
(set-face-attribute 'default nil :height 120 :family "DejaVu Sans Mono")
here. This got me
adjust_frame_size old native pixels 80x25 new native pixels 80x25 old text pixels 80x25 new text pixels 80x24 old text chars 80x25 new text chars 80x24
adjust_frame_size old native pixels 80x25 new native pixels 736x450 old text pixels 80x25 new text pixels 720x450 old text chars 80x25 new text chars 80x25
adjust_frame_size old native pixels 736x450 new native pixels 736x648 old text pixels 720x450 new text pixels 720x648 old text chars 80x25 new text chars 80x36
adjust_frame_size old native pixels 736x648 new native pixels 752x648 old text pixels 720x648 new text pixels 720x648 old text chars 80x36 new text chars 80x36
xg_frame_set_char_size old native pixels 752x648 new native pixels 752x648 outer pixels 752x673
xg_wm_set_size_hint scale 1 char width 9 vscroll 16 fringes 16 borders 0 base width 41 width inc 9
char height 18 menubar 25 toolbar 0 hscroll 0 borders 0 base height 43 height inc 18
xg_wm_set_size_hint scale 1 char width 9 vscroll 16 fringes 16 borders 0 base width 41 width inc 9
char height 18 menubar 25 toolbar 41 hscroll 0 borders 0 base height 84 height inc 18
xg_frame_set_char_size old native pixels 752x648 new native pixels 752x648 outer pixels 752x714 outer rest 0x0
x_new_font old char size 9x18 new char size 10x19 text chars 80x36 old text pixels 720x648 new text pixels 800x684
xg_wm_set_size_hint scale 1 char width 10 vscroll 16 fringes 16 borders 0 base width 42 width inc 10
char height 19 menubar 25 toolbar 41 hscroll 0 borders 0 base height 85 height inc 19
xg_frame_set_char_size old native pixels 752x648 new native pixels 832x684 outer pixels 832x750 outer rest 0x0
xg_frame_resized old native pixels 752x648 new native pixels 832x684
adjust_frame_size old native pixels 752x648 new native pixels 832x684 old text pixels 720x648 new text pixels 800x684 old text chars 80x36 new text chars 80x36
x_new_font old char size 10x19 new char size 11x23 text chars 80x36 old text pixels 800x684 new text pixels 880x828
xg_wm_set_size_hint scale 1 char width 11 vscroll 16 fringes 16 borders 0 base width 43 width inc 11
char height 23 menubar 25 toolbar 41 hscroll 0 borders 0 base height 89 height inc 23
xg_frame_set_char_size old native pixels 832x684 new native pixels 912x828 outer pixels 912x894 outer rest 0x0
xg_frame_resized old native pixels 832x684 new native pixels 912x828
adjust_frame_size old native pixels 832x684 new native pixels 912x828 old text pixels 800x684 new text pixels 880x828 old text chars 80x36 new text chars 80x36
x_new_font old char size 11x23 new char size 10x21 text chars 80x36 old text pixels 880x828 new text pixels 800x756
xg_wm_set_size_hint scale 1 char width 10 vscroll 16 fringes 16 borders 0 base width 42 width inc 10
char height 21 menubar 25 toolbar 41 hscroll 0 borders 0 base height 87 height inc 21
xg_frame_set_char_size old native pixels 912x828 new native pixels 832x756 outer pixels 832x822 outer rest 0x0
xg_frame_resized old native pixels 912x828 new native pixels 832x756
adjust_frame_size old native pixels 912x828 new native pixels 832x756 old text pixels 880x828 new text pixels 800x756 old text chars 80x36 new text chars 80x36
x_new_font old char size 10x21 new char size 10x19 text chars 80x36 old text pixels 800x756 new text pixels 800x684
xg_wm_set_size_hint scale 1 char width 10 vscroll 16 fringes 16 borders 0 base width 42 width inc 10
char height 19 menubar 25 toolbar 41 hscroll 0 borders 0 base height 85 height inc 19
xg_frame_set_char_size old native pixels 832x756 new native pixels 832x684 outer pixels 832x750 outer rest 0x0
xg_frame_resized old native pixels 832x756 new native pixels 832x684
adjust_frame_size old native pixels 832x756 new native pixels 832x684 old text pixels 800x756 new text pixels 800x684 old text chars 80x36 new text chars 80x36
where each x_new_font paragraph corresponds to one evaluation above.
Note the following two properties:
- As soon as things clear up, the size of the frame in text characters
is 80x36 and never changes after that. The same will have to hold for
your 'set-face-attribute' calls regardless of what the pixel sizes
say.
- "outer rest 0x0" stands for a zero rest when dividing the requested
size minus the base size by the size increments. The same will have
to hold for your 'set-face-attribute' calls.
Maybe I'm just lucky here or it's because I do not scale. I invite
everyone on GTK with some spare time to apply the attached
x_scale_font.diff, do some random 'set-face-attribute' calls and consult
the contents of the *foo* buffer. If the two properties don't hold,
something might be wrong and we should investigate that.
martin
[x_scale_font.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 05 Jan 2023 01:51:02 GMT)
Full text and
rfc822 format available.
Message #281 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Martin!
On 31/12/2022 21:01, martin rudalics wrote:
> where each x_new_font paragraph corresponds to one evaluation above.
> Note the following two properties:
>
> - As soon as things clear up, the size of the frame in text characters
> is 80x36 and never changes after that. The same will have to hold for
> your 'set-face-attribute' calls regardless of what the pixel sizes
> say.
>
> - "outer rest 0x0" stands for a zero rest when dividing the requested
> size minus the base size by the size increments. The same will have
> to hold for your 'set-face-attribute' calls.
>
> Maybe I'm just lucky here or it's because I do not scale. I invite
> everyone on GTK with some spare time to apply the attached
> x_scale_font.diff, do some random 'set-face-attribute' calls and consult
> the contents of the *foo* buffer. If the two properties don't hold,
> something might be wrong and we should investigate that.
Two points:
- My personal init script still results in a frame that's 84 columns
wide (according to frame-text-cols). There are no frame size settings in
the configuration.
- There are still widths of the frame where evaluating the previously
mentioned set-face-attribute form results in the frame shrinking
repeatedly until it reaches one of the "stable" widths. Like in prevous
test, the width 80 is stable. IOW, nothing seems to have changed WRT to
the shrinking behavior.
Here are the contents of *foo* accompanying the 'emacs -Q' session where
I first resize the frame to 90 columns (according to the wm) using the
mouse, and then evaluate the set-face-attribute form 7 times until it
reaches the width 80.
It does have a number of lines where "outer rest" is followed by values
other than 0x0. It's only 0x0 at the end.
[foo.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 05 Jan 2023 09:48:01 GMT)
Full text and
rfc822 format available.
Message #284 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> xg_wm_set_size_hint scale 2 char width 18 vscroll 32 fringes 16 borders 0 base width 33 width inc 9
> char height 36 menubar 50 toolbar 82 hscroll 0 borders 0 base height 84 height inc 18
> xg_frame_set_char_size old native pixels 1488x1296 new native pixels 1491x1296 outer pixels 745x714 outer rest 1x0
Apparently, rounding the native pixels doesn't make sense. Let's round
just the outer pixels instead. Patch attached.
martin
[x_scale_font.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 05 Jan 2023 14:15:02 GMT)
Full text and
rfc822 format available.
Message #287 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Martin,
On 05/01/2023 11:47, martin rudalics wrote:
> > xg_wm_set_size_hint scale 2 char width 18 vscroll 32 fringes 16
> borders 0 base width 33 width inc 9
> > char height 36 menubar 50 toolbar 82 hscroll 0 borders 0 base
> height 84 height inc 18
> > xg_frame_set_char_size old native pixels 1488x1296 new native pixels
> 1491x1296 outer pixels 745x714 outer rest 1x0
>
> Apparently, rounding the native pixels doesn't make sense. Let's round
> just the outer pixels instead. Patch attached.
I'm not seeing much of a change, if any:
- My init script stills results in a frame 84 columns wide.
- The frame still shrinks at certain width ranges.
Attached are the contents of foo after doing this:
(set-frame-width nil 102)
(set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
The second line was evaluated 5 times.
[foo.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 05 Jan 2023 17:00:02 GMT)
Full text and
rfc822 format available.
Message #290 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> I'm not seeing much of a change, if any:
>
> - My init script stills results in a frame 84 columns wide.
>
> - The frame still shrinks at certain width ranges.
>
> Attached are the contents of foo after doing this:
>
> (set-frame-width nil 102)
> (set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
>
> The second line was evaluated 5 times.
Thanks. It seems that we really have to disentangle the entire size
hint stuff to get reasonable outer sizes. Next patch attached.
martin
[x_scale_font.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 05 Jan 2023 19:09:02 GMT)
Full text and
rfc822 format available.
Message #293 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 05/01/2023 18:59, martin rudalics wrote:
> > I'm not seeing much of a change, if any:
> >
> > - My init script stills results in a frame 84 columns wide.
> >
> > - The frame still shrinks at certain width ranges.
> >
> > Attached are the contents of foo after doing this:
> >
> > (set-frame-width nil 102)
> > (set-face-attribute 'default nil :height 110 :family
> "InconsolataLGC")
> >
> > The second line was evaluated 5 times.
>
> Thanks. It seems that we really have to disentangle the entire size
> hint stuff to get reasonable outer sizes. Next patch attached.
- frame-text-cols from my init script is still ends up at 84 cols.
- 'emacs -Q' has its height shrinking again now.
- Its width is shrinking too, at certain widths. Not at 80 cols.
So I double-checked -- and both behaviors with the latest patch match
what the current (unpatched) emacs-29 does. I just hadn't noticed width
shrinking because I haven't tried to resize the frame first.
Attached are the contents of *foo* again after
(set-frame-width nil 102) ; x1
(set-face-attribute 'default nil :height 110 :family
"InconsolataLGC") ; x6
[foo.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 06 Jan 2023 17:48:02 GMT)
Full text and
rfc822 format available.
Message #296 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> So I double-checked -- and both behaviors with the latest patch match
> what the current (unpatched) emacs-29 does.
With one subtle difference: In the unpatched version the WM shrinks the
size. In the patched version we do it ourselves and the WM does what we
are asking for.
x_new_font old char size 18x36 new char size 21x45 text chars 102x36 old text pixels 1836x1296 new text pixels 2142x1620
xg_wm_set_size_hint scale 2 char width 21 toolbar 0 vscroll 32 fringes 16 borders 0 base width 34 width inc 10
char height 45 menubar 50 toolbar 82 hscroll 0 borders 0 base height 88 height inc 22
xg_frame_set_char_size old native pixels 1884x1296 new native pixels 2190x1620 outer pixels 1094x858 outer rest 0x0
xg_frame_resized old native pixels 1884x1296 new native pixels 2188x1584
adjust_frame_size old native pixels 1884x1296 new native pixels 2188x1584 old text pixels 1836x1296 new text pixels 2140x1584 old text chars 102x36 new text chars 101x35
Here we round down the outer pixel sizes from 1095x876 to 1094x858 to
meet the WM requirements (outer rest is 0x0 in all your steps). So
incidentally, I reverse-engineered the WM. Now let's try to round up
instead. I'm quite confident that this will make your frames grow.
martin
[x_scale_font.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 06 Jan 2023 18:16:02 GMT)
Full text and
rfc822 format available.
Message #299 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 06/01/2023 19:47, martin rudalics wrote:
> > So I double-checked -- and both behaviors with the latest patch match
> > what the current (unpatched) emacs-29 does.
>
> With one subtle difference: In the unpatched version the WM shrinks the
> size. In the patched version we do it ourselves and the WM does what we
> are asking for.
>
> x_new_font old char size 18x36 new char size 21x45 text chars 102x36
> old text pixels 1836x1296 new text pixels 2142x1620
> xg_wm_set_size_hint scale 2 char width 21 toolbar 0 vscroll 32
> fringes 16 borders 0 base width 34 width inc 10
> char height 45 menubar 50 toolbar 82 hscroll 0 borders 0 base
> height 88 height inc 22
> xg_frame_set_char_size old native pixels 1884x1296 new native pixels
> 2190x1620 outer pixels 1094x858 outer rest 0x0
> xg_frame_resized old native pixels 1884x1296 new native pixels 2188x1584
> adjust_frame_size old native pixels 1884x1296 new native pixels
> 2188x1584 old text pixels 1836x1296 new text pixels 2140x1584 old text
> chars 102x36 new text chars 101x35
>
> Here we round down the outer pixel sizes from 1095x876 to 1094x858 to
> meet the WM requirements (outer rest is 0x0 in all your steps). So
> incidentally, I reverse-engineered the WM. Now let's try to round up
> instead. I'm quite confident that this will make your frames grow.
Nope.
But this one seems the best one yet:
- No height shrinking.
- Width shrinks only once (at certain rare widths), and after that it is
stable.
Attaching *foo* after this:
(set-frame-width nil 113) ; x1
(set-face-attribute 'default nil :height 110 :family "InconsolataLGC") ; x3
[foo.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 06 Jan 2023 22:41:02 GMT)
Full text and
rfc822 format available.
Message #302 received at 52493 <at> debbugs.gnu.org (full text, mbox):
Another user reported an apparently similar problem in bug#60585. It
disappears when scroll-bars are turned off. Is that by any chance also
the case for the problem you see, Dmitry? It's not a proper solution of
course, but it might perhaps hint at a proper solution.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 06 Jan 2023 23:47:01 GMT)
Full text and
rfc822 format available.
Message #305 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 07/01/2023 00:40, Gregory Heytings wrote:
>
> Another user reported an apparently similar problem in bug#60585. It
> disappears when scroll-bars are turned off. Is that by any chance also
> the case for the problem you see, Dmitry? It's not a proper solution of
> course, but it might perhaps hint at a proper solution.
I checked with and without the last patch (the base behavior of
emacs-29): the scroll-bar doesn't seem to make a difference.
The original complaint was about height shrinking anyway, and the only
scroll-bar visible by default is the vertical one (on the right). It
doesn't seem likely that it would affect the calculation of the window's
height.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 06 Jan 2023 23:50:02 GMT)
Full text and
rfc822 format available.
Message #308 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> Another user reported an apparently similar problem in bug#60585. It
>> disappears when scroll-bars are turned off. Is that by any chance also
>> the case for the problem you see, Dmitry? It's not a proper solution
>> of course, but it might perhaps hint at a proper solution.
>
> I checked with and without the last patch (the base behavior of
> emacs-29): the scroll-bar doesn't seem to make a difference.
>
Okay, thanks.
>
> The original complaint was about height shrinking anyway, and the only
> scroll-bar visible by default is the vertical one (on the right). It
> doesn't seem likely that it would affect the calculation of the window's
> height.
>
Hmmm... Then can you perhaps also try with and without the menu-bar and
the tool-bar? Unless both are already disabled in your configuration, of
course.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sat, 07 Jan 2023 00:49:02 GMT)
Full text and
rfc822 format available.
Message #311 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 07/01/2023 01:49, Gregory Heytings wrote:
>> The original complaint was about height shrinking anyway, and the only
>> scroll-bar visible by default is the vertical one (on the right). It
>> doesn't seem likely that it would affect the calculation of the
>> window's height.
>>
>
> Hmmm... Then can you perhaps also try with and without the menu-bar and
> the tool-bar? Unless both are already disabled in your configuration,
> of course.
IIRC think we've tried this already in this thread.
Anyway, tested this again: no change.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sat, 07 Jan 2023 00:51:02 GMT)
Full text and
rfc822 format available.
Message #314 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>> The original complaint was about height shrinking anyway, and the only
>>> scroll-bar visible by default is the vertical one (on the right). It
>>> doesn't seem likely that it would affect the calculation of the
>>> window's height.
>>
>> Hmmm... Then can you perhaps also try with and without the menu-bar
>> and the tool-bar? Unless both are already disabled in your
>> configuration, of course.
>
> IIRC think we've tried this already in this thread.
>
I followed this thread but I forgot that, sorry.
>
> Anyway, tested this again: no change.
>
Okay, so it's something similar but different from bug#60585.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sat, 07 Jan 2023 09:16:01 GMT)
Full text and
rfc822 format available.
Message #317 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> - Width shrinks only once (at certain rare widths), and after that it is stable.
x_new_font old char size 21x45 new char size 17x37 text chars 113x36 old text pixels 2380x1628 new text pixels 1921x1332
xg_wm_set_size_hint scale 2 char width 17 toolbar 0 vscroll 32 fringes 16 borders 0 base width 32 width inc 8
char height 37 menubar 50 toolbar 82 hscroll 0 borders 0 base height 84 height inc 18
xg_frame_set_char_size old native pixels 2428x1628 new native pixels 1969x1332 outer pixels 984x732 outer rest 0x0
xg_frame_resized old native pixels 2428x1628 new native pixels 1968x1332
adjust_frame_size old native pixels 2428x1628 new native pixels 1968x1332 old text pixels 2380x1628 new text pixels 1920x1332 old text chars 113x36 new text chars 112x36
Here we calculate outer_width as (/ (+ 1921 32 16) 2) that is 984 and
outer_height as (/ (+ 1332 50 82) 2) that is 732. Since 1921 is impair
we lose one pixel due to scaling.
Now width_rest calculated as (% (- 984 32) 8) and height_rest calculated
as (% (- 732 84) 18) are both zero so we do not do any compensating and
lose one column after resizing.
I attach a version to handle this particular case. Let's see whether it
breaks something else.
martin
[x_scale_font.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sat, 07 Jan 2023 09:49:01 GMT)
Full text and
rfc822 format available.
Message #320 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Another user reported an apparently similar problem in bug#60585.
Looking at that thread I noticed the following:
1. Why does
I have just pulled latest Emacs and used with -Q option:
`global-text-scale-adjust' which I have used last days upon first
startup.
try to adjust the frame size in the first place? IIUC it should do that
iff 'global-text-scale-adjust-resizes-frames' is non-nil and that option
is nil with emacs -Q.
2. This argument brought by gijsbers on
https://github.com/ice-wm/icewm/issues/115
If you look at the height of 761 then 761 - 71 is not a multiple of the vertical increment 22.
Hence the height is adjusted to 753, because (753 - 71) / 22 = 31 exactly.
Maybe the size is adjusted to match the Inc and Base.
is valid. We'd have to investigate how we produce these values.
3. OTOH this argument again brought by gijsbers on
https://github.com/ice-wm/icewm/issues/115
IceWM historically has ignored the USSize field in the WM_NORMAL_HINTS
property. To enforce a size an app must set both the PMinSize and the
PMaxSize to the same value. Because there is no PMaxSize, icewm is free
to adjust the size to a value which is in accordance to the emacs
provided PBaseSize and PResizeInc. See the ICCCM for details. IceWM is
still standards conformant. It just has a different interpretation than
other WMs.
is not valid IMO. min_width and min_height specify the minimum sizes
that should be applied, for example, when the user tries to shrink a
window with the mouse by dragging one of its borders or edges. Emacs
does not handle these reasonably well but here I can see them with
applications like Firefox or Thunderbird. Together with max_width and
max_height these can be used to specify a fixed-size window. But "To
enforce a size an app must set both the PMinSize and the PMaxSize to the
same value." is something I cannot derive from any sources I have on
this subject.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sun, 08 Jan 2023 09:46:02 GMT)
Full text and
rfc822 format available.
Message #323 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> 2. This argument brought by gijsbers on
> https://github.com/ice-wm/icewm/issues/115
>
> If you look at the height of 761 then 761 - 71 is not a multiple of the vertical increment 22.
> Hence the height is adjusted to 753, because (753 - 71) / 22 = 31 exactly.
> Maybe the size is adjusted to match the Inc and Base.
>
> is valid. We'd have to investigate how we produce these values.
This ordering in EmacsFrameResize
change_frame_size (f, ew->core.width, ew->core.height,
false, true, false);
if (get_wm_shell (widget))
update_wm_hints (get_wm_shell (widget), ew);
makes no sense. We first ask for a size change and then update the size
hints.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sun, 08 Jan 2023 22:39:01 GMT)
Full text and
rfc822 format available.
Message #326 received at 52493 <at> debbugs.gnu.org (full text, mbox):
>
> OTOH this argument again brought by gijsbers on
> https://github.com/ice-wm/icewm/issues/115
>
> IceWM historically has ignored the USSize field in the WM_NORMAL_HINTS
> property. To enforce a size an app must set both the PMinSize and the
> PMaxSize to the same value. Because there is no PMaxSize, icewm is free
> to adjust the size to a value which is in accordance to the emacs
> provided PBaseSize and PResizeInc. See the ICCCM for details. IceWM is
> still standards conformant. It just has a different interpretation than
> other WMs.
>
> is not valid IMO. min_width and min_height specify the minimum sizes
> that should be applied, for example, when the user tries to shrink a
> window with the mouse by dragging one of its borders or edges. Emacs
> does not handle these reasonably well but here I can see them with
> applications like Firefox or Thunderbird. Together with max_width and
> max_height these can be used to specify a fixed-size window. But "To
> enforce a size an app must set both the PMinSize and the PMaxSize to the
> same value." is something I cannot derive from any sources I have on
> this subject.
>
As I just said in bug#60585, the bug seems to be specific to that window
manager (or at least to a few window managers), and disabling scroll-bars
or setting frame-resize-pixelwise to t fixes that problem. OTOH, what
gijsbers says does not seem unreasonable to me (but I'm not at all an
ICCCM expert), and I see here
https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html
that "Window Managers can identify a non-resizable window because its
minimum and maximum size in WM_NORMAL_HINTS will be the same." and that
"Windows can indicate that they are non-resizable by setting minheight =
maxheight and minwidth = maxwidth in the ICCCM WM_NORMAL_HINTS property."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Sun, 08 Jan 2023 23:24:01 GMT)
Full text and
rfc822 format available.
Message #329 received at 52493 <at> debbugs.gnu.org (full text, mbox):
>
> As I just said in bug#60585, the bug seems to be specific to that window
> manager (or at least to a few window managers), and disabling
> scroll-bars or setting frame-resize-pixelwise to t fixes that problem.
>
I found another window manager which behaves similarly: Openbox. I'm not
100% sure the cause is the same, but the two workarounds above also fix
that problem under Openbox, and I see this in its source code:
/*! The minimum size of the client window
If the min is > the max, then the window is not resizable
*/
Size min_size;
/*! The maximum size of the client window
If the min is > the max, then the window is not resizable
*/
Size max_size;
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Mon, 09 Jan 2023 00:13:01 GMT)
Full text and
rfc822 format available.
Message #332 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 07/01/2023 11:15, martin rudalics wrote:
> > - Width shrinks only once (at certain rare widths), and after that it
> is stable.
>
> x_new_font old char size 21x45 new char size 17x37 text chars 113x36
> old text pixels 2380x1628 new text pixels 1921x1332
> xg_wm_set_size_hint scale 2 char width 17 toolbar 0 vscroll 32
> fringes 16 borders 0 base width 32 width inc 8
> char height 37 menubar 50 toolbar 82 hscroll 0 borders 0 base
> height 84 height inc 18
> xg_frame_set_char_size old native pixels 2428x1628 new native pixels
> 1969x1332 outer pixels 984x732 outer rest 0x0
> xg_frame_resized old native pixels 2428x1628 new native pixels 1968x1332
> adjust_frame_size old native pixels 2428x1628 new native pixels
> 1968x1332 old text pixels 2380x1628 new text pixels 1920x1332 old text
> chars 113x36 new text chars 112x36
>
> Here we calculate outer_width as (/ (+ 1921 32 16) 2) that is 984 and
> outer_height as (/ (+ 1332 50 82) 2) that is 732. Since 1921 is impair
> we lose one pixel due to scaling.
>
> Now width_rest calculated as (% (- 984 32) 8) and height_rest calculated
> as (% (- 732 84) 18) are both zero so we do not do any compensating and
> lose one column after resizing.
>
> I attach a version to handle this particular case. Let's see whether it
> breaks something else.
Thanks, it's almost perfect:
- My init script ends up at 80x36 pretty reliably, after a bunch of
frame resizings.
- There seems to be no scenario for successive set-face-attribute calls
to keep resizing the frame.
Here's a few more complex ones that seem off:
;;; Scenario 1
;; 1.
(set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
;; to get the frame sized right
;; call (set-frame-size nil 80 36)
;; or (set-frame-size nil 160 36)
;; or don't if the frame is at that size already (which it should be)
;; (frame-text-lines) returns 36
;; 2. !important
;; manually resize the frame using the mouse to have one line less
;; (frame-text-lines) will continue to return 36
;; 3.
(set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
;; The frame will get resized to the previous dimensions.
;; Note that the return value of (frame-text-lines) doesn't change.
;;; Scenario 2
;; Do the same steps, except for the width instead of height.
;; Optionally, use different dimensions:
;; (set-frame-size nil 160 36)
;; These are the only ones I found to have this effect for both dimensions.
;; I'm guessing 160x72 will work as well, but that's bigger than my screen.
;;; Scenario 3
;; 1. From Scenario 1.
;; 2. Resize with the mouse both width and height, to have 1 less.
;; 3. Eval the set-frame-attribute form. Nothing happens, the frame size
stays the same.
;; Step 2 still doesn't change the return values of frame-text-cols/lines.
Attaching the contents of foo for all scenarios.
These are very much non-critical, of course.
[foo-scenario-1.txt (text/plain, attachment)]
[foo-scenario-2.txt (text/plain, attachment)]
[foo-scenario-3.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Mon, 09 Jan 2023 10:08:02 GMT)
Full text and
rfc822 format available.
Message #335 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Here's a few more complex ones that seem off:
>
> ;;; Scenario 1
> ;; 1.
> (set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
> ;; to get the frame sized right
> ;; call (set-frame-size nil 80 36)
> ;; or (set-frame-size nil 160 36)
> ;; or don't if the frame is at that size already (which it should be)
> ;; (frame-text-lines) returns 36
Note that a frame with the "right height" is only one where
(= (* (frame-char-height) (frame-text-lines)) (frame-text-height))
holds. Here, for example, a maximized frame does not have the "right
height".
> ;; 2. !important
> ;; manually resize the frame using the mouse to have one line less
> ;; (frame-text-lines) will continue to return 36
Manually resizing a frame with a scaling factor of 2 will be off by one
pixel when the font has impair height. There is nothing we can do about
that - the height increment we send to the WM must be an integer. The
result is that while the frame's pixel height changes and so does the
height of the frame on the display, the height in lines stays the same.
> ;; 3.
> (set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
> ;; The frame will get resized to the previous dimensions.
> ;; Note that the return value of (frame-text-lines) doesn't change.
Hopefully so. It's crucial that all executions of
(set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
starting with the same number of text lines result in the same pixel and
text heights.
> ;;; Scenario 2
> ;; Do the same steps, except for the width instead of height.
> ;; Optionally, use different dimensions:
> ;; (set-frame-size nil 160 36)
> ;; These are the only ones I found to have this effect for both dimensions.
> ;; I'm guessing 160x72 will work as well, but that's bigger than my screen.
IIUC this scenario is just a variation of the first one - with a
character size of 17x37 you will lose one pixel in both dimensions.
> ;;; Scenario 3
> ;; 1. From Scenario 1.
> ;; 2. Resize with the mouse both width and height, to have 1 less.
> ;; 3. Eval the set-frame-attribute form. Nothing happens, the frame size stays the same.
> ;; Step 2 still doesn't change the return values of frame-text-cols/lines.
IIUC these steps
xg_frame_resized old native pixels 1424x1368 new native pixels 1408x1368
adjust_frame_size old native pixels 1424x1368 new native pixels 1408x1368 old text pixels 1376x1368 new text pixels 1360x1368 old text chars 80x36 new text chars 80x36
xg_frame_resized old native pixels 1408x1368 new native pixels 1408x1332
adjust_frame_size old native pixels 1408x1368 new native pixels 1408x1332 old text pixels 1360x1368 new text pixels 1360x1332 old text chars 80x36 new text chars 80x36
represent two mouse operations that resize the frame by 16 pixels, first
the width, then the height. Both are less that the character size so
while again the size of the frame should have changed, the numbers of
text characters didn't.
x_new_font old char size 17x37 new char size 17x37 text chars 80x36 old text pixels 1360x1332 new text pixels 1360x1332
x_new_font old char size 17x37 new char size 17x37 text chars 80x36 old text pixels 1360x1332 new text pixels 1360x1332
Here we have (= (* 80 17) 1360) and (= (* 36 37) 1332) so
adjust_frame_size triggered by x_new_font correctly decides that the
frame size should stay the same.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Mon, 09 Jan 2023 10:10:02 GMT)
Full text and
rfc822 format available.
Message #338 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> As I just said in bug#60585, the bug seems to be specific to that
> window manager (or at least to a few window managers), and disabling
> scroll-bars or setting frame-resize-pixelwise to t fixes that problem.
I'm quite sure that even with scroll bars disabled the problem can
happen. 'frame-resize-pixelwise' OTOH means that size increments can be
ignored by the WM so that should fix the problem indeed.
> OTOH, what gijsbers says does not seem unreasonable to me (but I'm not
> at all an ICCCM expert), and I see here
>
> https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html
>
> that "Window Managers can identify a non-resizable window because its
> minimum and maximum size in WM_NORMAL_HINTS will be the same." and
> that "Windows can indicate that they are non-resizable by setting
> minheight = maxheight and minwidth = maxwidth in the ICCCM
> WM_NORMAL_HINTS property."
Right. But we eventually do want to resize that frame later and as soon
as the new character sizes make it to the size hints we see the effect.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Mon, 09 Jan 2023 17:29:02 GMT)
Full text and
rfc822 format available.
Message #341 received at 52493 <at> debbugs.gnu.org (full text, mbox):
Gregory Heytings <gregory <at> heytings.org> writes:
> Another user reported an apparently similar problem in bug#60585. It
> disappears when scroll-bars are turned off. Is that by any chance
> also the case for the problem you see, Dmitry? It's not a proper
> solution of course, but it might perhaps hint at a proper solution.
I've been following along this bug report because I was seeing something
similar. I'm using the sway Wayland wm, with this in my init:
(add-to-list 'default-frame-alist '(font . "Inconsolata-12"))
Turning scroll bars off also fixed it for me. I can't even quite
describe what "it" was, but lettering looked a little vertically
stretched and "ugly".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Mon, 09 Jan 2023 20:52:01 GMT)
Full text and
rfc822 format available.
Message #344 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 09/01/2023 12:07, martin rudalics wrote:
> > Here's a few more complex ones that seem off:
> >
> > ;;; Scenario 1
> > ;; 1.
> > (set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
> > ;; to get the frame sized right
> > ;; call (set-frame-size nil 80 36)
> > ;; or (set-frame-size nil 160 36)
> > ;; or don't if the frame is at that size already (which it should be)
> > ;; (frame-text-lines) returns 36
>
> Note that a frame with the "right height" is only one where
>
> (= (* (frame-char-height) (frame-text-lines)) (frame-text-height))
>
> holds. Here, for example, a maximized frame does not have the "right
> height".
Yeah ok, but none of the frames were maximized in those scenarios. And
the resizing by mouse "snapped" to the provided grid.
> > ;; 2. !important
> > ;; manually resize the frame using the mouse to have one line less
> > ;; (frame-text-lines) will continue to return 36
>
> Manually resizing a frame with a scaling factor of 2 will be off by one
> pixel when the font has impair height. There is nothing we can do about
> that - the height increment we send to the WM must be an integer. The
> result is that while the frame's pixel height changes and so does the
> height of the frame on the display, the height in lines stays the same.
I'm probably out of my depth here, but with 2x scaling, shouldn't the
height increment just be 2x larger than the original one? If N is
integer, 2xN must be an integer as well.
> > ;; 3.
> > (set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
> > ;; The frame will get resized to the previous dimensions.
> > ;; Note that the return value of (frame-text-lines) doesn't change.
>
> Hopefully so. It's crucial that all executions of
>
> (set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
>
> starting with the same number of text lines result in the same pixel and
> text heights.
Pixel dimensions do change in this scenario. But not the reported text
height.
> > ;;; Scenario 2
> > ;; Do the same steps, except for the width instead of height.
> > ;; Optionally, use different dimensions:
> > ;; (set-frame-size nil 160 36)
> > ;; These are the only ones I found to have this effect for both
> dimensions.
> > ;; I'm guessing 160x72 will work as well, but that's bigger than my
> screen.
>
> IIUC this scenario is just a variation of the first one - with a
> character size of 17x37 you will lose one pixel in both dimensions.
Yes, just width instead of height.
> > ;;; Scenario 3
> > ;; 1. From Scenario 1.
> > ;; 2. Resize with the mouse both width and height, to have 1 less.
> > ;; 3. Eval the set-frame-attribute form. Nothing happens, the frame
> size stays the same.
> > ;; Step 2 still doesn't change the return values of
> frame-text-cols/lines.
>
> IIUC these steps
>
> xg_frame_resized old native pixels 1424x1368 new native pixels 1408x1368
> adjust_frame_size old native pixels 1424x1368 new native pixels
> 1408x1368 old text pixels 1376x1368 new text pixels 1360x1368 old text
> chars 80x36 new text chars 80x36
> xg_frame_resized old native pixels 1408x1368 new native pixels 1408x1332
> adjust_frame_size old native pixels 1408x1368 new native pixels
> 1408x1332 old text pixels 1360x1368 new text pixels 1360x1332 old text
> chars 80x36 new text chars 80x36
>
> represent two mouse operations that resize the frame by 16 pixels, first
> the width, then the height. Both are less that the character size so
> while again the size of the frame should have changed, the numbers of
> text characters didn't.
The frame size didn't change either, however.
> x_new_font old char size 17x37 new char size 17x37 text chars 80x36 old
> text pixels 1360x1332 new text pixels 1360x1332
>
> x_new_font old char size 17x37 new char size 17x37 text chars 80x36 old
> text pixels 1360x1332 new text pixels 1360x1332
>
> Here we have (= (* 80 17) 1360) and (= (* 36 37) 1332) so
> adjust_frame_size triggered by x_new_font correctly decides that the
> frame size should stay the same.
All right. Where do we go from here?
The usability problems remaining are very minor, so if you're saying
Emacs is going right thing, we might as well go with the latest patch
and call it a day. Thank you.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Tue, 10 Jan 2023 12:07:02 GMT)
Full text and
rfc822 format available.
Message #347 received at 52493 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> Here, for example, a maximized frame does not have the "right
>> height".
>
> Yeah ok, but none of the frames were maximized in those scenarios.
I mentioned it because that's how it usually can be reproduced easily
with emacs -Q.
> And the resizing by mouse "snapped" to the provided grid.
The resolution of that grid is specified by Emacs via these four lines
size_hints.width_inc = frame_resize_pixelwise ? 1 : FRAME_COLUMN_WIDTH (f);
size_hints.height_inc = frame_resize_pixelwise ? 1 : FRAME_LINE_HEIGHT (f);
size_hints.width_inc /= scale;
size_hints.height_inc /= scale;
If you scale by 2 and you have a font with impair sizes, you lose one
pixel and the grid will be smaller than the character size. If we round
up in the last two lines, the grid will be larger than the character
size by one pixel. If we do not scale, the grid will have a resolution
of two characters. What would you prefer?
> I'm probably out of my depth here, but with 2x scaling, shouldn't the
> height increment just be 2x larger than the original one? If N is
> integer, 2xN must be an integer as well.
You're scaling down whatever you display probably because otherwise
displayed objects would appear to small for your eyes. That is, while
Emacs lives in a 4000x2000 pixels world say, it's presented to your eyes
in a 2000x1000 pixels form.
> Pixel dimensions do change in this scenario. But not the reported text height.
Right. That's what rounding is all about
>> xg_frame_resized old native pixels 1424x1368 new native pixels 1408x1368
>> adjust_frame_size old native pixels 1424x1368 new native pixels 1408x1368 old text pixels 1376x1368 new text pixels 1360x1368 old text chars 80x36 new text chars 80x36
>> xg_frame_resized old native pixels 1408x1368 new native pixels 1408x1332
>> adjust_frame_size old native pixels 1408x1368 new native pixels 1408x1332 old text pixels 1360x1368 new text pixels 1360x1332 old text chars 80x36 new text chars 80x36
>>
>> represent two mouse operations that resize the frame by 16 pixels, first
>> the width, then the height. Both are less that the character size so
>> while again the size of the frame should have changed, the numbers of
>> text characters didn't.
>
> The frame size didn't change either, however.
That's not what the numbers say. The first time, the width changed from
1424 to 1408 pixels. The second time, the height changed from 1368 to
1332 pixels.
> All right. Where do we go from here?
I think you should use the attached in your daily work. It's the same
as before with the tracing code omitted. If there are bigger problems,
use the former patch and post me the contents of *foo*.
> The usability problems remaining are very minor, so if you're saying Emacs is going right thing, we might as well go with the latest patch and call it a day. Thank you.
Note that I won't install anything in the near future because I've given
up synching with the repository. The last time I did, I spent a couple
of weeks to fix whatever got broken here.
martin
[x_scale_font_only.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 12 Jan 2023 00:35:01 GMT)
Full text and
rfc822 format available.
Message #350 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 10/01/2023 14:05, martin rudalics wrote:
> >> Here, for example, a maximized frame does not have the "right
> >> height".
> >
> > Yeah ok, but none of the frames were maximized in those scenarios.
>
> I mentioned it because that's how it usually can be reproduced easily
> with emacs -Q.
>
> > And the resizing by mouse "snapped" to the provided grid.
>
> The resolution of that grid is specified by Emacs via these four lines
>
> size_hints.width_inc = frame_resize_pixelwise ? 1 :
> FRAME_COLUMN_WIDTH (f);
> size_hints.height_inc = frame_resize_pixelwise ? 1 :
> FRAME_LINE_HEIGHT (f);
>
> size_hints.width_inc /= scale;
> size_hints.height_inc /= scale;
>
> If you scale by 2 and you have a font with impair sizes, you lose one
> pixel and the grid will be smaller than the character size. If we round
> up in the last two lines, the grid will be larger than the character
> size by one pixel.
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?
> If we do not scale, the grid will have a resolution
> of two characters. What would you prefer?
The current behavior seems more intuitive. Too bad we can't make it
behave precisely, but oh well.
> > I'm probably out of my depth here, but with 2x scaling, shouldn't the
> > height increment just be 2x larger than the original one? If N is
> > integer, 2xN must be an integer as well.
>
> You're scaling down whatever you display probably because otherwise
> displayed objects would appear to small for your eyes. That is, while
> Emacs lives in a 4000x2000 pixels world say, it's presented to your eyes
> in a 2000x1000 pixels form.
That makes sense.
> > Pixel dimensions do change in this scenario. But not the reported
> text height.
>
> Right. That's what rounding is all about
>
> >> xg_frame_resized old native pixels 1424x1368 new native pixels
> 1408x1368
> >> adjust_frame_size old native pixels 1424x1368 new native pixels
> 1408x1368 old text pixels 1376x1368 new text pixels 1360x1368 old text
> chars 80x36 new text chars 80x36
> >> xg_frame_resized old native pixels 1408x1368 new native pixels
> 1408x1332
> >> adjust_frame_size old native pixels 1408x1368 new native pixels
> 1408x1332 old text pixels 1360x1368 new text pixels 1360x1332 old text
> chars 80x36 new text chars 80x36
> >>
> >> represent two mouse operations that resize the frame by 16 pixels,
> first
> >> the width, then the height. Both are less that the character size so
> >> while again the size of the frame should have changed, the numbers of
> >> text characters didn't.
> >
> > The frame size didn't change either, however.
>
> That's not what the numbers say. The first time, the width changed from
> 1424 to 1408 pixels. The second time, the height changed from 1368 to
> 1332 pixels.
I was talking about the Scenario 3: the frame dimensions (pixelwise)
didn't change in it.
> > All right. Where do we go from here?
>
> I think you should use the attached in your daily work. It's the same
> as before with the tracing code omitted. If there are bigger problems,
> use the former patch and post me the contents of *foo*.
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.
I believe getting the details right is important, but it's probably not
worth too much as a personal patch.
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.
> > The usability problems remaining are very minor, so if you're saying
> Emacs is going right thing, we might as well go with the latest patch
> and call it a day. Thank you.
>
> Note that I won't install anything in the near future because I've given
> up synching with the repository. The last time I did, I spent a couple
> of weeks to fix whatever got broken here.
Is there anything I can do to help? Your patch applies cleanly to the
emacs-29 branch, at least.
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).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 12 Jan 2023 09:32:01 GMT)
Full text and
rfc822 format available.
Message #353 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> 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.
> 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.
adjust_frame_size old native pixels 80x25 new native pixels 80x25 old text pixels 80x25 new text pixels 80x24 old text chars 80x25 new text chars 80x24
adjust_frame_size old native pixels 80x25 new native pixels 1456x900 old text pixels 80x25 new text pixels 1440x900 old text chars 80x25 new text chars 80x25
adjust_frame_size old native pixels 1456x900 new native pixels 1456x1296 old text pixels 1440x900 new text pixels 1440x1296 old text chars 80x25 new text chars 80x36
adjust_frame_size old native pixels 1456x1296 new native pixels 1488x1296 old text pixels 1440x1296 new text pixels 1440x1296 old text chars 80x36 new text chars 80x36
xg_frame_set_char_size old native pixels 1488x1296 new native pixels 1488x1296 outer pixels 744x698
xg_frame_set_char_size old native pixels 1488x1296 new native pixels 1488x1296 outer pixels 744x673
xg_frame_resized old native pixels 1488x1296 new native pixels 1488x1346
xg_frame_resized old native pixels 1488x1296 new native pixels 1488x1296
xg_wm_set_size_hint scale 2 char width 18 toolbar 0 vscroll 32 fringes 16 borders 0 base width 33 width inc 9
char height 36 menubar 50 toolbar 0 hscroll 0 borders 0 base height 43 height inc 18
xg_wm_set_size_hint scale 2 char width 18 toolbar 0 vscroll 32 fringes 16 borders 0 base width 33 width inc 9
char height 36 menubar 50 toolbar 82 hscroll 0 borders 0 base height 84 height inc 18
xg_frame_set_char_size old native pixels 1488x1296 new native pixels 1488x1296 outer pixels 744x714 outer rest 0x0
x_new_font old char size 18x36 new char size 21x45 text chars 80x36 old text pixels 1440x1296 new text pixels 1680x1620
xg_wm_set_size_hint scale 2 char width 21 toolbar 0 vscroll 32 fringes 16 borders 0 base width 34 width inc 10
char height 45 menubar 50 toolbar 82 hscroll 0 borders 0 base height 88 height inc 22
xg_frame_set_char_size old native pixels 1488x1296 new native pixels 1728x1620 outer pixels 874x880 outer rest 0x0
xg_frame_resized old native pixels 1488x1296 new native pixels 1748x1628
adjust_frame_size old native pixels 1488x1296 new native pixels 1748x1628 old text pixels 1440x1296 new text pixels 1700x1628 old text chars 80x36 new text chars 80x36
x_new_font old char size 21x45 new char size 17x37 text chars 80x36 old text pixels 1700x1628 new text pixels 1360x1332
xg_wm_set_size_hint scale 2 char width 17 toolbar 0 vscroll 32 fringes 16 borders 0 base width 32 width inc 8
char height 37 menubar 50 toolbar 82 hscroll 0 borders 0 base height 84 height inc 18
xg_frame_set_char_size old native pixels 1748x1628 new native pixels 1408x1332 outer pixels 712x750 outer rest 0x0
xg_frame_resized old native pixels 1748x1628 new native pixels 1424x1368
adjust_frame_size old native pixels 1748x1628 new native pixels 1424x1368 old text pixels 1700x1628 new text pixels 1376x1368 old text chars 80x36 new text chars 80x36
xg_frame_resized old native pixels 1424x1368 new native pixels 1408x1368
adjust_frame_size old native pixels 1424x1368 new native pixels 1408x1368 old text pixels 1376x1368 new text pixels 1360x1368 old text chars 80x36 new text chars 80x36
xg_frame_resized old native pixels 1408x1368 new native pixels 1408x1332
adjust_frame_size old native pixels 1408x1368 new native pixels 1408x1332 old text pixels 1360x1368 new text pixels 1360x1332 old text chars 80x36 new text chars 80x36
x_new_font old char size 17x37 new char size 17x37 text chars 80x36 old text pixels 1360x1332 new text pixels 1360x1332
x_new_font old char size 17x37 new char size 17x37 text chars 80x36 old text pixels 1360x1332 new text pixels 1360x1332
> 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.
> 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. 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.
> 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.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 12 Jan 2023 09:47:01 GMT)
Full text and
rfc822 format available.
Message #356 received at 52493 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 12 Jan 2023 10:31:35 +0100, martin rudalics <rudalics <at> gmx.at> said:
>> 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?
martin> We send half the actual value because Robert (IIRC) has coded it that
martin> way. I never scale here and so I can't tell whether that's the right
martin> approach. Have a look at Bug#20432 where Jan says something about GTK
martin> messing things up.
Itʼs done that way because thatʼs the way it works, not because of any
decision on my part. When scaling is in use, a screen that has eg
1920x1080 "physical pixels" is presented to us as being 960x540
"virtual pixels". Since Emacs uses physical pixels internally, we need
to divide all the numbers by 2.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 12 Jan 2023 10:24:02 GMT)
Full text and
rfc822 format available.
Message #359 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> Itʼs done that way because thatʼs the way it works, not because of any
> decision on my part. When scaling is in use, a screen that has eg
> 1920x1080 "physical pixels" is presented to us as being 960x540
> "virtual pixels". Since Emacs uses physical pixels internally, we need
> to divide all the numbers by 2.
That's what I understood from your code and also tried to tell Dmitry.
So I suppose that GTK and the WM deal with virtual pixels only and the
gtk_window_resize API is what separates us from them. But I've never
been able to understand where we translate virtual size values back to
our ones whenever we call xg_frame_resized. Bear with me - I have no
good idea how scaling works internally.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Thu, 12 Jan 2023 23:55:02 GMT)
Full text and
rfc822 format available.
Message #362 received at 52493 <at> debbugs.gnu.org (full text, mbox):
On 12/01/2023 11:46, Robert Pluim wrote:
>>>>>> On Thu, 12 Jan 2023 10:31:35 +0100, martin rudalics<rudalics <at> gmx.at> said:
> >> 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?
> martin> We send half the actual value because Robert (IIRC) has coded it that
> martin> way. I never scale here and so I can't tell whether that's the right
> martin> approach. Have a look at Bug#20432 where Jan says something about GTK
> martin> messing things up.
>
> Itʼs done that way because thatʼs the way it works, not because of any
> decision on my part. When scaling is in use, a screen that has eg
> 1920x1080 "physical pixels" is presented to us as being 960x540
> "virtual pixels". Since Emacs uses physical pixels internally, we need
> to divide all the numbers by 2.
But depending on the scaling of the display, the :height attribute of a
face translates to a different height value in pixels, doesn't it?
So at some point there has to be some scaling up performed first. I
suppose the uneven height of a font in pixels might be picked up because
that's the closest available shape, but perhaps the "actual" doubled
height value might be used for line height etc?
I'm just guessing, sorry if that's way off.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 13 Jan 2023 00:37:01 GMT)
Full text and
rfc822 format available.
Message #365 received at 52493 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52493; Package
emacs.
(Fri, 13 Jan 2023 08:39:02 GMT)
Full text and
rfc822 format available.
Message #368 received at 52493 <at> debbugs.gnu.org (full text, mbox):
> I cannot reproduce the problem reported in bug#60585, with or without that patch (with GNOME).
That one is a real treat, however. With our current bug we are occupied
with things going awry when we want to explicitly change the size of a
frame. In Bug#60585 we do not want to change the size of a frame.
Rather we want to keep its size fixed when changing the default font's
size.
The problem is not reproducible with GTK because there we set the size
hints only when we want to resize a frame. With the Lucid build we set
size hints more often.
martin
This bug report was last modified 2 years and 249 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.