GNU bug report logs -
#31745
default-frame-alist sizing parameters set in ~/.emacs are not applied correctly
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 31745 in the body.
You can then email your comments to 31745 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Thu, 07 Jun 2018 07:50:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"" <mark.liu.li.ming <at> foxmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 07 Jun 2018 07:50: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)]
This bug occurs in both emacs 26.1 in the official archlinux repo and emacs-git 27.0.50 in aur when i am using MATE 1.20.0 with its default window manager.
My configuration about frame size in .emacs is as follows:
(add-to-list 'default-frame-alist '(top . 0))
(add-to-list 'default-frame-alist '(left . 0))
(add-to-list 'default-frame-alist '(width . 120))
(add-to-list 'default-frame-alist '(height . 47))
(add-to-list 'default-frame-alist '(font . "Sarasa Mono CL 12"))
If i launch emacs with a file in terminal, such as `emacs .emacs` or run `emacs --geometry 120x47`, all works will.
But in other cases, such as launch emacs in terminal using command `emacs`, emacs will display a smaller frame in its default size, but text area will treat itself as if it is actually in an 120x47-size frame. For example, it will not show mode line, because the mode line is "displayed" on line 46, but the frame is actually 80x36 and if one line in scratch has more than 80 charactors, it will not display `right-arrow` or `right-curly-arrow`.
I also try to add `(x-parse-geometry "120x47+0+0")` in file `.emacs`, but it doesn't work.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Thu, 07 Jun 2018 13:28:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 31745 <at> debbugs.gnu.org (full text, mbox):
"" <mark.liu.li.ming <at> foxmail.com> writes:
> This bug occurs in both emacs 26.1 in the official archlinux repo and emacs-git 27.0.50 in aur when i am using MATE 1.20.0 with its default window manager.
>
>
>
> My configuration about frame size in .emacs is as follows:
> (add-to-list 'default-frame-alist '(top . 0))
> (add-to-list 'default-frame-alist '(left . 0))
> (add-to-list 'default-frame-alist '(width . 120))
> (add-to-list 'default-frame-alist '(height . 47))
> (add-to-list 'default-frame-alist '(font . "Sarasa Mono CL 12"))
>
>
>
> If i launch emacs with a file in terminal, such as `emacs .emacs` or run `emacs --geometry 120x47`, all works will.
>
>
> But in other cases, such as launch emacs in terminal using command
> `emacs`, emacs will display a smaller frame in its default size, but
> text area will treat itself as if it is actually in an 120x47-size
> frame. For example, it will not show mode line, because the mode line
> is "displayed" on line 46, but the frame is actually 80x36 and if one
> line in scratch has more than 80 charactors, it will not display
> `right-arrow` or `right-curly-arrow`.
>
>
> I also try to add `(x-parse-geometry "120x47+0+0")` in file `.emacs`, but it doesn't work.
Unfortunately you've cut out all the information from report-emacs-bug
that might help us narrow this down. Could you provide the values of
system-configuration-options
system-configuration-features
(or just run `report-emacs-bug' again and paste the results into a reply to
this bug report).
Does this also happen when running 'emacs -Q -l .emacs', with .emacs
containing only your frame size configuration?
Thanks
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Thu, 07 Jun 2018 15:16:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 31745 <at> debbugs.gnu.org (full text, mbox):
[please keep the bug address in CC]
"刘力铭" <mark.liu.li.ming <at> foxmail.com> writes:
> This not happen when running `emacs -Q -l .emacs`.
>
>
> Add then, i tried to comment different regions in my configuration
> file, and found it seems that only if i comment both `(require
> 'em-tramp)` and line 239-241 which confige mode line's theme, this bug
> will not happen. And if i uncomment either of them, the bug will
> occur. `(require 'em-tramp)` triggers it more offen than the latter.
Interesting. I donʼt see anything obvious in em-tramp that would cause
this, but that doesnʼt matter, because 'emacs -q' does this here for
me on Fedora 28, but only when I have scaling turned on. Are you
running XWayland by any chance? Do you have scaling enabled?
Thanks
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Fri, 08 Jun 2018 01:20:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 31745 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I am not using XWayland. Is scaling about font size? But if i comment the line `(add-to-list 'default-frame-alist '(font . "Sarasa Mono CL 12"))`, it also occurs.
------------------ 原始邮件 ------------------
发件人: "Robert Pluim"<rpluim <at> gmail.com>;
发送时间: 2018年6月7日(星期四) 晚上11:15
收件人: "刘力铭"<mark.liu.li.ming <at> foxmail.com>;
抄送: "31745"<31745 <at> debbugs.gnu.org>;
主题: Re: 回复： bug#31745: Frame's bug whenwindow-system
[please keep the bug address in CC]
"刘力铭" <mark.liu.li.ming <at> foxmail.com> writes:
> This not happen when running `emacs -Q -l .emacs`.
>
>
> Add then, i tried to comment different regions in my configuration
> file, and found it seems that only if i comment both `(require
> 'em-tramp)` and line 239-241 which confige mode line's theme, this bug
> will not happen. And if i uncomment either of them, the bug will
> occur. `(require 'em-tramp)` triggers it more offen than the latter.
Interesting. I donʼt see anything obvious in em-tramp that would cause
this, but that doesnʼt matter, because 'emacs -q' does this here for
me on Fedora 28, but only when I have scaling turned on. Are you
running XWayland by any chance? Do you have scaling enabled?
Thanks
Robert
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Fri, 08 Jun 2018 08:36:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 31745 <at> debbugs.gnu.org (full text, mbox):
"刘力铭" <mark.liu.li.ming <at> foxmail.com> writes:
> I am not using XWayland. Is scaling about font size? But if i
> comment the line `(add-to-list 'default-frame-alist '(font . "Sarasa
> Mono CL 12"))`, it also occurs.
The scaling I mean is the type where you have a HiDpi screen (eg 4K),
and tell your window manager to pretend that each pixel is actually
twice the size. Itʼs usually configured either in your display
settings or in gnome-tweak-tool or similar. I donʼt know offhand how
itʼs done in Mate. It can cause problems when Emacs doesnʼt apply the
scaling factor correctly.
Itʼs possible this is related to recent versions of Gnome (my system
where it doesnʼt reproduce is still on 3.18)
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Fri, 08 Jun 2018 11:34:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 31745 <at> debbugs.gnu.org (full text, mbox):
"刘力铭" <mark.liu.li.ming <at> foxmail.com> writes:
[you dropped the bug address again]
>> The scaling I mean is the type where you have a HiDpi screen (eg 4K),
>> and tell your window manager to pretend that each pixel is actually
>> twice the size. Itʼs usually configured either in your display
>> settings or in gnome-tweak-tool or similar. I donʼt know offhand how
>> itʼs done in Mate. It can cause problems when Emacs doesnʼt apply the
>> scaling factor correctly.
>>
>> Itʼs possible this is related to recent versions of Gnome (my system
>> where it doesnʼt reproduce is still on 3.18)
>
>
>
> My screen's resolution is actually 141 dpi, but X's default is 96 dpi and i don't change it. I also set font's dpi in this value via `.font.conf` and `.Xresources`.
>
>
> And now, i change it to 141 via `/etc/X11/xorg.conf.d/90-monitor.conf` and also change the dpi of font. The reasults of `xdpyinfo | grep -B2 resolution` is as follows:
>
>
> screen #0:
> dimensions: 1920x1080 pixels (345x194 millimeters)
> resolution: 141x141 dots per inch
>
>
>
> And the reasult of `xrdb -query` is also 141. But the behavior of emacs is the same as it before.
> Or is 96 dpi means scaling is turned off？ If so, this may not the problem about scaling.
It may not be scaling. I can see something similar here that goes away
when I specify --no-x-resources to emacs. Which x-resource is
responsible I donʼt know.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Fri, 08 Jun 2018 12:45:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 31745 <at> debbugs.gnu.org (full text, mbox):
"刘力铭" <mark.liu.li.ming <at> foxmail.com> writes:
>> It may not be scaling. I can see something similar here that goes away
>> when I specify --no-x-resources to emacs. Which x-resource is
>> responsible I donʼt know.
>>
>> Robert
>
>
>
> `--no-x-resources` is not work for me, but it may be related to `(setq sml/no-confirm-load-theme t)`. If i comment this rather than `(require 'em-tramp)` and the line customize theme, emacs works well.
> Emacs will always ask me if trust the customized theme without this statement and then show the frame in correct size.
>
And my reproducer has just stopped reproducing, so I can't make any
progress until it starts happening again.
It seems like thereʼs some kind of race condition going on when
creating the initial frame. It seems pretty sensitive though, as soon
as I start looking for the cause it goes away.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Thu, 21 Jun 2018 11:42:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 31745 <at> debbugs.gnu.org (full text, mbox):
retitle 31745 default-frame-alist sizing parameters set in ~/.emacs are not applied correctly
quit
Robert Pluim <rpluim <at> gmail.com> writes:
> And my reproducer has just stopped reproducing, so I can't make any
> progress until it starts happening again.
>
> It seems like thereʼs some kind of race condition going on when
> creating the initial frame. It seems pretty sensitive though, as soon
> as I start looking for the cause it goes away.
Maybe changing x-wait-for-event-timeout would affect it?
Changed bug title to 'default-frame-alist sizing parameters set in ~/.emacs are not applied correctly' from 'Frame's bug when window-system'
Request was from
Noam Postavsky <npostavs <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Thu, 21 Jun 2018 11:42:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Thu, 21 Jun 2018 12:00:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 31745 <at> debbugs.gnu.org (full text, mbox):
Noam Postavsky <npostavs <at> gmail.com> writes:
> retitle 31745 default-frame-alist sizing parameters set in ~/.emacs
> are not applied correctly
> quit
>
> Robert Pluim <rpluim <at> gmail.com> writes:
>
>> And my reproducer has just stopped reproducing, so I can't make any
>> progress until it starts happening again.
>>
>> It seems like thereʼs some kind of race condition going on when
>> creating the initial frame. It seems pretty sensitive though, as soon
>> as I start looking for the cause it goes away.
>
> Maybe changing x-wait-for-event-timeout would affect it?
Iʼd forgotten about that one. Setting that to nil makes it more
reproducible, though not 100%. Now, how to figure out why itʼs
happening? Martin?
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Fri, 22 Jun 2018 08:57:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 31745 <at> debbugs.gnu.org (full text, mbox):
> It seems like thereʼs some kind of race condition going on when
> creating the initial frame. It seems pretty sensitive though, as soon
> as I start looking for the cause it goes away.
You could try setting 'frame-size-history' to something like '(1000)
and look at what 'frame--size-history' tells. Since this does not
cover the initial frame, you may have to do a hard setting in frame.c.
IME debugging interactions with the window system is hardly indicative
because when you hit a breakpoint you usually hide any race conditions
that might occur in normal execution.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Fri, 22 Jun 2018 14:45:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 31745 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
martin rudalics <rudalics <at> gmx.at> writes:
>> It seems like thereʼs some kind of race condition going on when
>> creating the initial frame. It seems pretty sensitive though, as soon
>> as I start looking for the cause it goes away.
>
> You could try setting 'frame-size-history' to something like '(1000)
> and look at what 'frame--size-history' tells. Since this does not
> cover the initial frame, you may have to do a hard setting in frame.c.
>
So when everything kinda works:
(965
(#<frame emacs <at> rpluim-ubuntu 0x133fd20> adjust-frame-size-1
(1120 1080 1120 1080)
(set-window-configuration 1))
(#<frame emacs <at> rpluim-ubuntu 0x133fd20> adjust-frame-size-3
(1820 1680 1120 1080)
(1849 1680 1149 1080))
(#<frame emacs <at> rpluim-ubuntu 0x133fd20> adjust-frame-size-1
(1820 1680 1120 1080)
(change-frame-size 5))
(#<frame emacs <at> rpluim-ubuntu 0x133fd20> xg-frame-resized
(1820 1680 1120 1080)
nil)
(#<frame emacs <at> rpluim-ubuntu 0x133fd20> adjust-frame-size-3
(1120 1080 1820 1680)
(1149 1080 1849 1680))
So we start small, go big, then go small again, but the end result,
even though it looks correct, is actually wrong:
(frame-parameter nil 'height)
36
(frame-parameter nil 'width)
80
Although I asked for:
(add-to-list 'default-frame-alist '(width . 130))
(add-to-list 'default-frame-alist '(height . 56))
in the .el Iʼm loading.
When it doesnʼt work:
(967
(#<frame emacs <at> rpluim-ubuntu 0x133fd20> adjust-frame-size-1
(1820 1680 1820 1680)
(set-window-configuration 1))
(#<frame emacs <at> rpluim-ubuntu 0x133fd20> adjust-frame-size-3
(1120 1080 1820 1680)
(1149 1080 1849 1680))
(#<frame emacs <at> rpluim-ubuntu 0x133fd20> adjust-frame-size-1
(1120 1080 1820 1680)
(change-frame-size 5))
(#<frame emacs <at> rpluim-ubuntu 0x133fd20> xg-frame-resized
(1120 1080 1120 1080)
nil)
(#<frame emacs <at> rpluim-ubuntu 0x133fd20> xg-frame-set-char-size-3
(1120 1080 1120 1080)
(1149 1183))
we start big, go small, and stay small. The frame is actually the same
size as previous, but emacs' state is messed up:
(frame-parameter nil 'height)
56
(frame-parameter nil 'width)
130
Iʼve attached both full traces.
Robert
[31745-trace.OK (text/plain, attachment)]
[31745-trace.NOK (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Fri, 22 Jun 2018 15:31:01 GMT)
Full text and
rfc822 format available.
Message #40 received at 31745 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Follow is the trace resulting from `emacs`:
Frame size history of #<frame emacs <at> a550jk4200 0x11a7420>
FRAME-NOTICE-USER nil ((font . Sarasa Mono CL 12) (height . 47) (width . 120) (left . 0) (top . 0))
adjust-frame-size-1 (560 576 640 720) (font 3)
adjust-frame-size-2 (560 576 640 720) (nil nil)
xg-frame-set-char-size-3 (560 576 640 720) (672 749)
adjust-frame-size-1 (560 576 960 940) (x-set-frame-parameters 1)
adjust-frame-size-2 (560 576 960 940) (nil nil)
xg-frame-set-char-size-3 (560 576 960 940) (992 969)
xg-frame-resized (560 576 640 720) nil
adjust-frame-size-1 (560 576 640 720) (change-frame-size 5)
adjust-frame-size-3 (560 576 640 720) (592 576 672 720)
xg-frame-resized (640 720 960 940) nil
update-frame-tool-bar nil nil
adjust-frame-size-1 (640 720 640 720) (tool-bar-lines 2)
adjust-frame-size-2 (640 720 640 720) (nil nil)
xg-frame-set-char-size-3 (640 720 640 720) (672 791)
adjust-frame-size-1 (640 720 960 940) (change-frame-size 5)
xg-frame-resized (640 720 640 720) nil
adjust-frame-size-3 (640 720 960 940) (672 720 992 940)
adjust-frame-size-1 (960 940 960 940) (set-window-configuration 1)
adjust-frame-size-1 (960 940 960 940) (set-window-configuration 1)
And this is the trace resulting from `emacs --geometry="120x47"`:
Frame size history of #<frame emacs <at> a550jk4200 0x3435000>
FRAME-NOTICE-USER nil ((font . Sarasa Mono CL 12) (left . 0) (top . 0))
adjust-frame-size-1 (840 752 960 940) (font 3)
adjust-frame-size-2 (840 752 960 940) (nil nil)
xg-frame-set-char-size-3 (840 752 960 940) (992 969)
xg-frame-resized (840 752 960 940) nil
adjust-frame-size-1 (840 752 960 940) (change-frame-size 5)
adjust-frame-size-3 (840 752 960 940) (872 752 992 940)
update-frame-tool-bar nil nil
adjust-frame-size-1 (960 940 960 940) (tool-bar-lines 2)
adjust-frame-size-2 (960 940 960 940) (nil nil)
xg-frame-set-char-size-3 (960 940 960 940) (992 1011)
xg-frame-resized (960 940 960 940) nil
adjust-frame-size-1 (960 940 960 940) (set-window-configuration 1)
adjust-frame-size-1 (960 940 960 940) (set-window-configuration 1)
The trace resulting from `emacs .emacs` is:
Frame size history of #<frame emacs <at> a550jk4200 0x11a7420>
FRAME-NOTICE-USER nil ((font . Sarasa Mono CL 12) (height . 47) (width . 120) (left . 0) (top . 0))
adjust-frame-size-1 (560 576 640 720) (font 3)
adjust-frame-size-2 (560 576 640 720) (nil nil)
xg-frame-set-char-size-3 (560 576 640 720) (672 749)
xg-frame-resized (560 576 640 720) nil
adjust-frame-size-1 (560 576 640 720) (change-frame-size 5)
adjust-frame-size-3 (560 576 640 720) (592 576 672 720)
adjust-frame-size-1 (640 720 960 940) (x-set-frame-parameters 1)
adjust-frame-size-2 (640 720 960 940) (nil nil)
xg-frame-set-char-size-3 (640 720 960 940) (992 969)
xg-frame-resized (640 720 960 940) nil
adjust-frame-size-1 (640 720 960 940) (change-frame-size 5)
adjust-frame-size-3 (640 720 960 940) (672 720 992 940)
update-frame-tool-bar nil nil
adjust-frame-size-1 (960 940 960 940) (tool-bar-lines 2)
adjust-frame-size-2 (960 940 960 940) (nil nil)
xg-frame-set-char-size-3 (960 940 960 940) (992 1011)
xg-frame-resized (960 940 960 940) nil
adjust-frame-size-1 (960 940 960 940) (set-window-configuration 1)
Traces are not fully the same with each other that resulting from a same command. This is another trace resulting from `emacs`:
Frame size history of #<frame emacs <at> a550jk4200 0x11a7420>
FRAME-NOTICE-USER nil ((font . Sarasa Mono CL 12) (height . 47) (width . 120) (left . 0) (top . 0))
adjust-frame-size-1 (560 576 640 720) (font 3)
adjust-frame-size-2 (560 576 640 720) (nil nil)
xg-frame-set-char-size-3 (560 576 640 720) (672 749)
adjust-frame-size-1 (560 576 960 940) (x-set-frame-parameters 1)
adjust-frame-size-2 (560 576 960 940) (nil nil)
xg-frame-set-char-size-3 (560 576 960 940) (992 969)
xg-frame-resized (560 576 640 720) nil
adjust-frame-size-1 (560 576 640 720) (change-frame-size 5)
adjust-frame-size-3 (560 576 640 720) (592 576 672 720)
xg-frame-resized (640 720 960 940) nil
update-frame-tool-bar nil nil
adjust-frame-size-1 (640 720 640 720) (tool-bar-lines 2)
adjust-frame-size-2 (640 720 640 720) (nil nil)
xg-frame-set-char-size-3 (640 720 640 720) (672 791)
adjust-frame-size-1 (640 720 960 940) (change-frame-size 5)
xg-frame-resized (640 720 640 720) nil
adjust-frame-size-3 (640 720 960 940) (672 720 992 940)
adjust-frame-size-1 (960 940 960 940) (set-window-configuration 1)
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Sat, 23 Jun 2018 08:41:01 GMT)
Full text and
rfc822 format available.
Message #43 received at 31745 <at> debbugs.gnu.org (full text, mbox):
> So when everything kinda works:
[...]
> So we start small, go big, then go small again, but the end result,
> even though it looks correct, is actually wrong:
>
> (frame-parameter nil 'height)
> 36
> (frame-parameter nil 'width)
> 80
>
> Although I asked for:
>
> (add-to-list 'default-frame-alist '(width . 130))
> (add-to-list 'default-frame-alist '(height . 56))
>
> in the .el Iʼm loading.
Isn't "when everything kinda works" the end result "is actually wrong"
somehow contradictory? I think you mean to say that the end result is
consistent but fails to process the values you specified.
> When it doesnʼt work:
[...]
> we start big, go small, and stay small. The frame is actually the same
> size as previous, but emacs' state is messed up:
>
> (frame-parameter nil 'height)
> 56
> (frame-parameter nil 'width)
> 130
This means that you get the expected values for the parameters but the
frame itself has the wrong sizes?
What did you use to produce this and does it only happen with scaling?
I still do not understand the nature of this bug in the first place.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Sat, 23 Jun 2018 08:41:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 31745 <at> debbugs.gnu.org (full text, mbox):
Thanks. If the bug does happen without the font setting
(font . Sarasa Mono CL 12)
please do not set the font in future experiments because it
complicates the mental translation between character size values (like
47 or 120) and the pixel values produced by the trace.
I'm not sure whether you ever confirmed Robert's question: Does the
bug happen when you turn off scaling of your display?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Sat, 23 Jun 2018 11:51:01 GMT)
Full text and
rfc822 format available.
Message #49 received at 31745 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
The bug does happen without this font setting. Traces are as follows:
`emacs`(the bug occurs in this case):
Frame size history of #<frame emacs <at> a550jk4200 0x11a7420>
FRAME-NOTICE-USER nil ((height . 47) (width . 120) (left . 0) (top . 0))
adjust-frame-size-1 (560 576 840 752) (x-set-frame-parameters 1)
adjust-frame-size-2 (560 576 840 752) (nil nil)
xg-frame-set-char-size-3 (560 576 840 752) (872 781)
xg-frame-resized (560 576 840 752) nil
update-frame-tool-bar nil nil
adjust-frame-size-1 (560 576 560 576) (tool-bar-lines 2)
adjust-frame-size-2 (560 576 560 576) (nil nil)
xg-frame-set-char-size-3 (560 576 560 576) (592 647)
xg-frame-resized (560 576 560 576) nil
adjust-frame-size-1 (560 576 840 752) (change-frame-size 5)
adjust-frame-size-3 (560 576 840 752) (592 576 872 752)
adjust-frame-size-1 (840 752 840 752) (set-window-configuration 1)
`emacs --geometry="120x47"`:
Frame size history of #<frame emacs <at> a550jk4200 0x11a7470>
FRAME-NOTICE-USER nil ((left . 0) (top . 0))
update-frame-tool-bar nil nil
adjust-frame-size-1 (840 752 840 752) (tool-bar-lines 2)
adjust-frame-size-2 (840 752 840 752) (nil nil)
xg-frame-set-char-size-3 (840 752 840 752) (872 823)
xg-frame-resized (840 752 840 752) nil
adjust-frame-size-1 (840 752 840 752) (set-window-configuration 1)
`emacs .emacs`:
Frame size history of #<frame emacs <at> a550jk4200 0x11a7420>
FRAME-NOTICE-USER nil ((height . 47) (width . 120) (left . 0) (top . 0))
adjust-frame-size-1 (560 576 840 752) (x-set-frame-parameters 1)
adjust-frame-size-2 (560 576 840 752) (nil nil)
xg-frame-set-char-size-3 (560 576 840 752) (872 781)
xg-frame-resized (560 576 840 752) nil
adjust-frame-size-1 (560 576 840 752) (change-frame-size 5)
adjust-frame-size-3 (560 576 840 752) (592 576 872 752)
update-frame-tool-bar nil nil
adjust-frame-size-1 (840 752 840 752) (tool-bar-lines 2)
adjust-frame-size-2 (840 752 840 752) (nil nil)
xg-frame-set-char-size-3 (840 752 840 752) (872 823)
xg-frame-resized (840 752 840 752) nil
adjust-frame-size-1 (840 752 840 752) (set-window-configuration 1)
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Wed, 27 Jun 2018 07:36:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 31745 <at> debbugs.gnu.org (full text, mbox):
> The bug does happen without this font setting. Traces are as follows:
Thanks. But you have not answered the question:
Does the bug happen when you turn off scaling of your display?
I'm not sure how to tell whether a display is scaled and how to turn
scaling off and on. Maybe Robert can tell us more.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Wed, 27 Jun 2018 09:02:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 31745 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
martin rudalics <rudalics <at> gmx.at> writes:
>> So when everything kinda works:
> [...]
>> So we start small, go big, then go small again, but the end result,
>> even though it looks correct, is actually wrong:
>>
>> (frame-parameter nil 'height)
>> 36
>> (frame-parameter nil 'width)
>> 80
>>
>> Although I asked for:
>>
>> (add-to-list 'default-frame-alist '(width . 130))
>> (add-to-list 'default-frame-alist '(height . 56))
>>
>> in the .el Iʼm loading.
>
> Isn't "when everything kinda works" the end result "is actually wrong"
> somehow contradictory? I think you mean to say that the end result is
> consistent but fails to process the values you specified.
>
Yes, which is why I used the modifier 'kinda'. The emacs state is
consistent and usable, but not as requested.
>> When it doesnʼt work:
> [...]
>> we start big, go small, and stay small. The frame is actually the same
>> size as previous, but emacs' state is messed up:
>>
>> (frame-parameter nil 'height)
>> 56
>> (frame-parameter nil 'width)
>> 130
>
> This means that you get the expected values for the parameters but the
> frame itself has the wrong sizes?
Yes, plus parts of emacs obviously believe the frame-parameters, since
the minibuffer and modeline are not visible.
> What did you use to produce this and does it only happen with scaling?
> I still do not understand the nature of this bug in the first place.
src/emacs -q --no-site-file --no-site-lisp --no-splash --eval '(setq
x-wait-for-event-timeout nil)' -l ../emacs-real-26/31745.el
(although it happens with non-nil x-wait-for-event-timeout as well)
where 31745.el is based off the original reporter's .emacs (attached).
Scaling is not in effect.
Regards
Robert
[31745.el (application/emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Wed, 27 Jun 2018 09:15:01 GMT)
Full text and
rfc822 format available.
Message #58 received at 31745 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> The bug does happen without this font setting. Traces are as follows:
>
> Thanks. But you have not answered the question:
>
> Does the bug happen when you turn off scaling of your display?
>
> I'm not sure how to tell whether a display is scaled and how to turn
> scaling off and on. Maybe Robert can tell us more.
It depends. For anything older than GTK 3.10 we look at GDK_SCALE,
otherwise we inspect the GTK widget directly (but the widget value
again comes either from GDK_SCALE or from the window manager
settings).
We donʼt have an exposed API for checking the scale. I donʼt think we
need one (and this bug is independent of scaling for me).
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Thu, 28 Jun 2018 08:04:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 31745 <at> debbugs.gnu.org (full text, mbox):
> Yes, plus parts of emacs obviously believe the frame-parameters, since
> the minibuffer and modeline are not visible.
>
>> What did you use to produce this and does it only happen with scaling?
>> I still do not understand the nature of this bug in the first place.
>
> src/emacs -q --no-site-file --no-site-lisp --no-splash --eval '(setq
> x-wait-for-event-timeout nil)' -l ../emacs-real-26/31745.el
>
> (although it happens with non-nil x-wait-for-event-timeout as well)
> where 31745.el is based off the original reporter's .emacs (attached).
Hmmm... Does the behavior reproduce just with
emacs -Q --eval "(setq default-frame-alist '((left . 0) (top . 0) (width . 130) (height . 56)))"
56 lines is by default too large for my screen so I can't see the
modeline either. But I suppose that's not what you both mean.
Also, when you evaluate
(setq default-frame-alist '((left . 0) (top . 0) (width . 130) (height . 56)))
in such a miscreated frame does it turn to the expected state?
BTW we still don't have any valid toolkit/window manager details for
this report yet. Could you please provide some?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Thu, 28 Jun 2018 08:27:01 GMT)
Full text and
rfc822 format available.
Message #64 received at 31745 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Yes, plus parts of emacs obviously believe the frame-parameters, since
>> the minibuffer and modeline are not visible.
>>
>>> What did you use to produce this and does it only happen with scaling?
>>> I still do not understand the nature of this bug in the first place.
>>
>> src/emacs -q --no-site-file --no-site-lisp --no-splash --eval '(setq
>> x-wait-for-event-timeout nil)' -l ../emacs-real-26/31745.el
>>
>> (although it happens with non-nil x-wait-for-event-timeout as well)
>> where 31745.el is based off the original reporter's .emacs (attached).
>
> Hmmm... Does the behavior reproduce just with
>
> emacs -Q --eval "(setq default-frame-alist '((left . 0) (top . 0) (width . 130) (height . 56)))"
>
Yes.
> 56 lines is by default too large for my screen so I can't see the
> modeline either. But I suppose that's not what you both mean.
The frame is fully visible, itʼs just not showing the minibuffer nor
the mode-line. And itʼs the wrong size (itʼs the same size as when
runing just emacs -Q, ie 80x36).
> Also, when you evaluate
>
> (setq default-frame-alist '((left . 0) (top . 0) (width . 130) (height . 56)))
>
> in such a miscreated frame does it turn to the expected state?
No, and I donʼt see how it would, that just affects the next frame
creation, no? Besides, itʼs already set to that :-)
> BTW we still don't have any valid toolkit/window manager details for
> this report yet. Could you please provide some?
x86_64-pc-linux-gnu, GTK+ Version 3.18.9, running KDE plasma 5.12.5,
using kwin. Basically Ubuntu 16.04 with KDE on top.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Thu, 28 Jun 2018 08:35:01 GMT)
Full text and
rfc822 format available.
Message #67 received at 31745 <at> debbugs.gnu.org (full text, mbox):
>> Hmmm... Does the behavior reproduce just with
>>
>> emacs -Q --eval "(setq default-frame-alist '((left . 0) (top . 0) (width . 130) (height . 56)))"
>>
>
> Yes.
That's a good bad base. Let's stick to this.
>> Also, when you evaluate
>>
>> (setq default-frame-alist '((left . 0) (top . 0) (width . 130) (height . 56)))
>>
>> in such a miscreated frame does it turn to the expected state?
>
> No, and I donʼt see how it would, that just affects the next frame
> creation, no? Besides, itʼs already set to that :-)
I'm too silly. I obviously meant
(modify-frame-parameters nil '((left . 0) (top . 0) (width . 130) (height . 56)))
What give (frame-pixel-width) and (frame-pixel-height) for this frame
in the bad and good states?
> x86_64-pc-linux-gnu, GTK+ Version 3.18.9, running KDE plasma 5.12.5,
> using kwin. Basically Ubuntu 16.04 with KDE on top.
Can you try with another toolkit or X without any toolkit so we can
tell whether this is GTK or window manager specific?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Thu, 28 Jun 2018 09:07:01 GMT)
Full text and
rfc822 format available.
Message #70 received at 31745 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>
> I'm too silly. I obviously meant
>
> (modify-frame-parameters nil '((left . 0) (top . 0) (width . 130) (height . 56)))
>
That does nothing, but the following resizes the frame:
(modify-frame-parameters nil '((left . 0) (top . 0) (width . 100) (height . 48)))
And has done the right thing:
(frame-parameter nil 'height) => 48
(frame-parameter nil 'width) => 100
> What give (frame-pixel-width) and (frame-pixel-height) for this frame
> in the bad and good states?
>
Bad:
(frame-pixel-width) => 1849
(frame-pixel-height) => 1680
Good:
(frame-pixel-width) => 1849
(frame-pixel-height) => 1680
>> x86_64-pc-linux-gnu, GTK+ Version 3.18.9, running KDE plasma 5.12.5,
>> using kwin. Basically Ubuntu 16.04 with KDE on top.
>
> Can you try with another toolkit or X without any toolkit so we can
> tell whether this is GTK or window manager specific?
--with-x-toolkit={none,lucid} both work fine (although you can see the
modeline of the frame appear as if it were 80x36, and then it
resizes correctly to 130x56).
Regards
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Thu, 28 Jun 2018 12:26:02 GMT)
Full text and
rfc822 format available.
Message #73 received at 31745 <at> debbugs.gnu.org (full text, mbox):
>> (modify-frame-parameters nil '((left . 0) (top . 0) (width . 130) (height . 56)))
>>
>
> That does nothing, but the following resizes the frame:
>
> (modify-frame-parameters nil '((left . 0) (top . 0) (width . 100) (height . 48)))
>
> And has done the right thing:
>
> (frame-parameter nil 'height) => 48
> (frame-parameter nil 'width) => 100
Looks like the missing link. If your window manager refuses to resize
the frame, it probably decides that it would not fit on the screen.
Please increase separately from 48 and 100 till you find the
problematic value and compare it against your workspace size.
>> What give (frame-pixel-width) and (frame-pixel-height) for this frame
>> in the bad and good states?
>>
>
> Bad:
>
> (frame-pixel-width) => 1849
> (frame-pixel-height) => 1680
>
> Good:
>
> (frame-pixel-width) => 1849
> (frame-pixel-height) => 1680
This looks like our bad. Somehow we decide that the window manager
will comply and set the values we asked for. Do these values also
occur with emacs -Q followed by
(modify-frame-parameters nil '((left . 0) (top . 0) (width . 130) (height . 56)))
I suppose not since otherwise you would have probably told me so.
>> Can you try with another toolkit or X without any toolkit so we can
>> tell whether this is GTK or window manager specific?
>
> --with-x-toolkit={none,lucid} both work fine (although you can see the
> modeline of the frame appear as if it were 80x36, and then it
> resizes correctly to 130x56).
This implies that the bug is somewhere in our interception of X
messages and letting GTK not see them (otherwise GTK should have
reported an error). However, it contradicts the assumption that the
window manager refuses to resize our frame since otherwise it would
have done so for the Lucid build too. Rather it seems that GTK itself
decides that the frame is too large to fit on the screen. But without
signalling an error?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Thu, 28 Jun 2018 14:17:02 GMT)
Full text and
rfc822 format available.
Message #76 received at 31745 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
martin rudalics <rudalics <at> gmx.at> writes:
>>> (modify-frame-parameters nil '((left . 0) (top . 0) (width . 130) (height . 56)))
>>>
>>
>> That does nothing, but the following resizes the frame:
>>
>> (modify-frame-parameters nil '((left . 0) (top . 0) (width . 100) (height . 48)))
>>
>> And has done the right thing:
>>
>> (frame-parameter nil 'height) => 48
>> (frame-parameter nil 'width) => 100
>
> Looks like the missing link. If your window manager refuses to resize
> the frame, it probably decides that it would not fit on the screen.
> Please increase separately from 48 and 100 till you find the
> problematic value and compare it against your workspace size.
>
130x56 fits on my screen fine, so Iʼm not sure thatʼs what's
happening. Once the initial frame has been created I can modify its
size without any problems.
>> Good:
>>
>> (frame-pixel-width) => 1849
>> (frame-pixel-height) => 1680
>
> This looks like our bad. Somehow we decide that the window manager
> will comply and set the values we asked for. Do these values also
> occur with emacs -Q followed by
>
> (modify-frame-parameters nil '((left . 0) (top . 0) (width . 130) (height . 56)))
>
> I suppose not since otherwise you would have probably told me so.
Yes, I get the same values for frame-pixel-{width,height} if I modify
the frame size after startup. Thatʼs not surprising to me, the issue
is somewhere during the setup of the initial frame.
>>> Can you try with another toolkit or X without any toolkit so we can
>>> tell whether this is GTK or window manager specific?
>>
>> --with-x-toolkit={none,lucid} both work fine (although you can see the
>> modeline of the frame appear as if it were 80x36, and then it
>> resizes correctly to 130x56).
>
> This implies that the bug is somewhere in our interception of X
> messages and letting GTK not see them (otherwise GTK should have
> reported an error). However, it contradicts the assumption that the
> window manager refuses to resize our frame since otherwise it would
> have done so for the Lucid build too. Rather it seems that GTK itself
> decides that the frame is too large to fit on the screen. But without
> signalling an error?
Youʼre right that the frame is not resized the way we requested, but
it doesnʼt seem to be because GTK thinks itʼs too big, since eg
src/emacs -Q --eval "(setq default-frame-alist '((left . 0) (top . 0) (width . 79) (height . 35)))"
can result in emacs thinking the frame is *smaller* than what's
actually displayed, so the modeline is drawn too high, and the
minibuffer has empty lines drawn underneath it. Screenshot:
[Selection_029.png (image/png, inline)]
[Message part 3 (text/plain, inline)]
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Fri, 29 Jun 2018 08:43:01 GMT)
Full text and
rfc822 format available.
Message #79 received at 31745 <at> debbugs.gnu.org (full text, mbox):
> 130x56 fits on my screen fine, so Iʼm not sure thatʼs what's
> happening. Once the initial frame has been created I can modify its
> size without any problems.
Maybe it does not fit with the initial window position chosen by the
window manager.
> Thatʼs not surprising to me, the issue
> is somewhere during the setup of the initial frame.
Window managers can be more picky to make sure a new frame fits on the
screen. For an already existing frame they usually accept that it
moves off-screen. Can you position any other application's first
window off-screen?
> Youʼre right that the frame is not resized the way we requested, but
> it doesnʼt seem to be because GTK thinks itʼs too big, since eg
>
> src/emacs -Q --eval "(setq default-frame-alist '((left . 0) (top . 0) (width . 79) (height . 35)))"
>
> can result in emacs thinking the frame is *smaller* than what's
> actually displayed, so the modeline is drawn too high, and the
> minibuffer has empty lines drawn underneath it. Screenshot:
If you continue to work with this frame without (implicitly)
triggering a frame resize, does Emacs keep on thinking so forever?
Does the buggy behavior trigger also when you do not set the 'left'
and 'top' parameters, that is, if you purely resize the frame and not
move it at the same time? If so, we maybe should try to use
gdk_window_move_resize or whatever there is now. ISTR that I tried it
once and it seemed to work but dropped the idea later because I had
difficulties figuring out a suitable interface.
Also, does setting 'x-gtk-use-window-move' change anything? It could
conceptually, for GTK 3.18.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Fri, 29 Jun 2018 11:59:01 GMT)
Full text and
rfc822 format available.
Message #82 received at 31745 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> 130x56 fits on my screen fine, so Iʼm not sure thatʼs what's
>> happening. Once the initial frame has been created I can modify its
>> size without any problems.
>
> Maybe it does not fit with the initial window position chosen by the
> window manager.
>
>> Thatʼs not surprising to me, the issue
>> is somewhere during the setup of the initial frame.
>
> Window managers can be more picky to make sure a new frame fits on the
> screen. For an already existing frame they usually accept that it
> moves off-screen. Can you position any other application's first
> window off-screen?
>
Iʼve tried eg
xterm -geometry 80x36+-50+-50
but the resulting window is always fully visible. Itʼs possible the
window manager hasn't fully implemented support for negative offsets,
itʼs somewhat obscure.
>> Youʼre right that the frame is not resized the way we requested, but
>> it doesnʼt seem to be because GTK thinks itʼs too big, since eg
>>
>> src/emacs -Q --eval "(setq default-frame-alist '((left . 0) (top . 0) (width . 79) (height . 35)))"
>>
>> can result in emacs thinking the frame is *smaller* than what's
>> actually displayed, so the modeline is drawn too high, and the
>> minibuffer has empty lines drawn underneath it. Screenshot:
>
> If you continue to work with this frame without (implicitly)
> triggering a frame resize, does Emacs keep on thinking so forever?
Yes.
> Does the buggy behavior trigger also when you do not set the 'left'
> and 'top' parameters, that is, if you purely resize the frame and not
> move it at the same time? If so, we maybe should try to use
> gdk_window_move_resize or whatever there is now. ISTR that I tried it
> once and it seemed to work but dropped the idea later because I had
> difficulties figuring out a suitable interface.
src/emacs -Q --eval "(setq default-frame-alist '((width . 79) (height . 35)))"
shows the same behaviour.
> Also, does setting 'x-gtk-use-window-move' change anything? It could
> conceptually, for GTK 3.18.
Thatʼs set to t by default. Setting it to nil doesnʼt change anything.
Regards
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Sat, 30 Jun 2018 08:35:01 GMT)
Full text and
rfc822 format available.
Message #85 received at 31745 <at> debbugs.gnu.org (full text, mbox):
> xterm -geometry 80x36+-50+-50
>
> but the resulting window is always fully visible. Itʼs possible the
> window manager hasn't fully implemented support for negative offsets,
> itʼs somewhat obscure.
It's normal - some window managers simply refuse to position an
initial window partially offscreen.
I have to return to my earlier request which you replied to as follows:
>> (modify-frame-parameters nil '((left . 0) (top . 0) (width . 130) (height . 56)))
>>
>
> That does nothing, but the following resizes the frame:
>
> (modify-frame-parameters nil '((left . 0) (top . 0) (width . 100) (height . 48)))
>
> And has done the right thing:
>
> (frame-parameter nil 'height) => 48
> (frame-parameter nil 'width) => 100
Did you call 'modify-frame-parameters' in your initial file or in the
initial frame? I was interested in the latter.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Sat, 30 Jun 2018 09:14:01 GMT)
Full text and
rfc822 format available.
Message #88 received at 31745 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>>> (modify-frame-parameters nil '((left . 0) (top . 0) (width . 130) (height . 56)))
>>>
>>
>> That does nothing, but the following resizes the frame:
>>
>> (modify-frame-parameters nil '((left . 0) (top . 0) (width . 100) (height . 48)))
>>
>> And has done the right thing:
>>
>> (frame-parameter nil 'height) => 48
>> (frame-parameter nil 'width) => 100
>
> Did you call 'modify-frame-parameters' in your initial file or in the
> initial frame? I was interested in the latter.
From the *scratch* buffer, after emacs has finished displaying the
initial frame.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Sun, 01 Jul 2018 09:03:02 GMT)
Full text and
rfc822 format available.
Message #91 received at 31745 <at> debbugs.gnu.org (full text, mbox):
>>From the *scratch* buffer, after emacs has finished displaying the
> initial frame.
Then let's ignore the initial frame behavior for the moment and
concentrate on this. We have to find out the reason why the window
manager might refuse to resize our frame as requested. There can't be
many of them. Either the size wrt to the frame's position is too
large. This could be verified by finding a corresponding threshold
value beyond which the frame cannot be resized. Or the value
specified does not result in an integral multiple of character sizes.
This could be verified by setting 'frame-resize-pixelwise' to t. I
can't see any other reason. Can you?
In either case it would be interesting to have a look at the sources
of the window manager you use.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Mon, 02 Jul 2018 05:00:02 GMT)
Full text and
rfc822 format available.
Message #94 received at 31745 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
It is so strange that after i updated my package for emacs from melpa sources (not stable) today, this bug seems to disappear on my machine and the history of frame size caused by `emacs` is just the same as `emacs .emacs` which frame size is fine.
All of my packages can be seen from .emacs file i had provided before martin joined in this session, and the packages i updated today are company, company-lsp, cquery, flycheck, geiser, lsp-mode, lsp-ui, markdown-mode, smartparens and yasnippet.
I don't change any other things, and before this update, my configuration works well on emacs25, but have this problem on the archlinux's first release of emacs26 and emacs27 from aur as i posted before. But my configuration works well after this update on emacs 26.1-1 and emacs27.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Mon, 02 Jul 2018 14:32:01 GMT)
Full text and
rfc822 format available.
Message #97 received at 31745 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>>>From the *scratch* buffer, after emacs has finished displaying the
>> initial frame.
>
> Then let's ignore the initial frame behavior for the moment and
> concentrate on this. We have to find out the reason why the window
> manager might refuse to resize our frame as requested. There can't be
> many of them. Either the size wrt to the frame's position is too
> large. This could be verified by finding a corresponding threshold
> value beyond which the frame cannot be resized. Or the value
> specified does not result in an integral multiple of character sizes.
> This could be verified by setting 'frame-resize-pixelwise' to t. I
> can't see any other reason. Can you?
>
> In either case it would be interesting to have a look at the sources
> of the window manager you use.
Indeed. Iʼve just tried using Gnome on the exact same system with the
exact same emacs binary, so the only difference is the window manager:
I can't reproduce the issue. So thereʼs a difference in how we
interact with Kwin causing this (Mark, which window manager do you use?).
Regards
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Mon, 02 Jul 2018 15:27:02 GMT)
Full text and
rfc822 format available.
Message #100 received at 31745 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I'm using MATE 1.20.0 with it's default window manager, Metacity (Marco) on Archlinux.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Thu, 28 Apr 2022 10:43:02 GMT)
Full text and
rfc822 format available.
Message #103 received at 31745 <at> debbugs.gnu.org (full text, mbox):
"" <mark.liu.li.ming <at> foxmail.com> writes:
> I'm using MATE 1.20.0 with it's default window manager, Metacity (Marco) on
> Archlinux.
(I'm going through old bug reports that unfortunately weren't resolved
at the time.)
I'm not able to reproduce the issue with Emacs 29/Gnome shell/Debian
bookworm. Mark, are you still seeing this problem with newer Emacs/OS
versions?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Thu, 28 Apr 2022 10:43:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31745; Package
emacs.
(Thu, 26 May 2022 12:50:02 GMT)
Full text and
rfc822 format available.
Message #108 received at 31745 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> I'm not able to reproduce the issue with Emacs 29/Gnome shell/Debian
> bookworm. Mark, are you still seeing this problem with newer Emacs/OS
> versions?
More information was requested, but no response was given within a
month, so I'm closing this bug report. If the problem still exists,
please respond to this email and we'll reopen the bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
31745 <at> debbugs.gnu.org and "������" <mark.liu.li.ming <at> foxmail.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Thu, 26 May 2022 12:50:04 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 24 Jun 2022 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 297 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.