bug#31745: 回复： bug#31745: 回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

bug#31745: 回复： bug#31745: 回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[Robert Pluim]

"刘力铭" <mark.liu.li.ming@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

bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[Robert Pluim]

"刘力铭" <mark.liu.li.ming@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

bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[Noam Postavsky]

retitle 31745 default-frame-alist sizing parameters set in ~/.emacs are not applied correctly
quit

Robert Pluim <rpluim@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?

bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[Robert Pluim]

Noam Postavsky <npostavs@gmail.com> writes:

> retitle 31745 default-frame-alist sizing parameters set in ~/.emacs
> are not applied correctly
> quit
>
> Robert Pluim <rpluim@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

bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[martin rudalics]

 > 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

bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[Robert Pluim]

[-- Attachment #1: Type: text/plain, Size: 2248 bytes --]

martin rudalics <rudalics@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@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (1120 1080 1120 1080)
	  (set-window-configuration 1))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-3
	  (1820 1680 1120 1080)
	  (1849 1680 1149 1080))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (1820 1680 1120 1080)
	  (change-frame-size 5))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> xg-frame-resized
	  (1820 1680 1120 1080)
	  nil)
 (#<frame emacs@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@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (1820 1680 1820 1680)
	  (set-window-configuration 1))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-3
	  (1120 1080 1820 1680)
	  (1149 1080 1849 1680))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (1120 1080 1820 1680)
	  (change-frame-size 5))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> xg-frame-resized
	  (1120 1080 1120 1080)
	  nil)
 (#<frame emacs@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


[-- Attachment #2: 31745-trace.OK --]
[-- Type: text/plain, Size: 4503 bytes --]

frame-size-history is a variable defined in ‘C source code’.
Its value is shown below.

Documentation:
History of frame size adjustments.
If non-nil, list recording frame size adjustment.  Adjustments are
recorded only if the first element of this list is a positive number.
Adding an adjustment decrements that number by one.

The remaining elements are the adjustments.  Each adjustment is a list
of four elements ‘frame’, ‘function’, ‘sizes’ and ‘more’.  ‘frame’ is
the affected frame and ‘function’ the invoking function.  ‘sizes’ is
usually a list of four elements ‘old-width’, ‘old-height’, ‘new-width’
and ‘new-height’ representing the old and new sizes recorded/requested
by ‘function’.  ‘more’ is a list with additional information.

The function ‘frame--size-history’ displays the value of this variable
in a more readable form.

Value:
(965
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (1120 1080 1120 1080)
	  (set-window-configuration 1))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-3
	  (1820 1680 1120 1080)
	  (1849 1680 1149 1080))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (1820 1680 1120 1080)
	  (change-frame-size 5))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> xg-frame-resized
	  (1820 1680 1120 1080)
	  nil)
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-3
	  (1120 1080 1820 1680)
	  (1149 1080 1849 1680))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (1120 1080 1820 1680)
	  (change-frame-size 5))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> xg-frame-set-char-size-3
	  (1120 1080 1120 1080)
	  (1149 1183))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-2
	  (1120 1080 1120 1080)
	  (nil nil))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (1120 1080 1120 1080)
	  (tool-bar-lines 2))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> update-frame-tool-bar nil nil)
 (#<frame emacs@rpluim-ubuntu 0x133fd20> xg-frame-resized
	  (1120 1080 1820 1680)
	  nil)
 (#<frame emacs@rpluim-ubuntu 0x133fd20> xg-frame-set-char-size-3
	  (1120 1080 1820 1680)
	  (1849 1725))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-2
	  (1120 1080 1820 1680)
	  (nil nil))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (1120 1080 1820 1680)
	  (x-set-frame-parameters 1))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> "FRAME-NOTICE-USER" nil
	  ((height . 56)
	   (width . 130)
	   (left . 0)
	   (top . 0)))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> "MAKE-FRAME")
 (#<frame emacs@rpluim-ubuntu 0x133fd20> x-handle-net-wm-state nil
	  (nil nil))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> x-handle-net-wm-state nil
	  (nil nil))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> x-handle-net-wm-state nil
	  (nil nil))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> x-handle-net-wm-state nil
	  (nil nil))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> x-handle-net-wm-state nil
	  (nil nil))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> xg-frame-resized
	  (1120 1080 1120 1080)
	  nil)
 (#<frame emacs@rpluim-ubuntu 0x133fd20> x-set-fullscreen nil
	  (nil nil))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (1120 1080 1120 1080)
	  (xg-frame-set-char-size 5))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> xg-frame-set-char-size-3
	  (1120 1080 1120 1080)
	  (1149 1125))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-2
	  (1120 1080 1120 1080)
	  (nil nil))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (1120 1080 1120 1080)
	  (x-create-frame-2 0))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (1120 1080 1120 1080)
	  (menu-bar-lines 2))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (1120 1080 1120 1080)
	  (scroll-bar-height 3))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-3
	  (1120 1080 1120 1080)
	  (1136 1080 1149 1080))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (1120 1080 1120 1080)
	  (scroll-bar-width 3))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-3
	  (10 10 140 300)
	  (10 10 156 300))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (10 10 140 300)
	  (x-create-frame-1 5))
 (#<dead frame F1 0xc89040> adjust-frame-size-3
	 (10 10 10 9)
	 (10 10 10 10))
 (#<dead frame F1 0xc89040> adjust-frame-size-1
	 (10 10 10 9)
	 (change-frame-size 5)))

[-- Attachment #3: 31745-trace.NOK --]
[-- Type: text/plain, Size: 4273 bytes --]

frame-size-history is a variable defined in ‘C source code’.
Its value is shown below.

Documentation:
History of frame size adjustments.
If non-nil, list recording frame size adjustment.  Adjustments are
recorded only if the first element of this list is a positive number.
Adding an adjustment decrements that number by one.

The remaining elements are the adjustments.  Each adjustment is a list
of four elements ‘frame’, ‘function’, ‘sizes’ and ‘more’.  ‘frame’ is
the affected frame and ‘function’ the invoking function.  ‘sizes’ is
usually a list of four elements ‘old-width’, ‘old-height’, ‘new-width’
and ‘new-height’ representing the old and new sizes recorded/requested
by ‘function’.  ‘more’ is a list with additional information.

The function ‘frame--size-history’ displays the value of this variable
in a more readable form.

Value:
(967
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (1820 1680 1820 1680)
	  (set-window-configuration 1))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-3
	  (1120 1080 1820 1680)
	  (1149 1080 1849 1680))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (1120 1080 1820 1680)
	  (change-frame-size 5))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> xg-frame-resized
	  (1120 1080 1120 1080)
	  nil)
 (#<frame emacs@rpluim-ubuntu 0x133fd20> xg-frame-set-char-size-3
	  (1120 1080 1120 1080)
	  (1149 1183))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-2
	  (1120 1080 1120 1080)
	  (nil nil))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (1120 1080 1120 1080)
	  (tool-bar-lines 2))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> update-frame-tool-bar nil nil)
 (#<frame emacs@rpluim-ubuntu 0x133fd20> xg-frame-resized
	  (1120 1080 1820 1680)
	  nil)
 (#<frame emacs@rpluim-ubuntu 0x133fd20> xg-frame-set-char-size-3
	  (1120 1080 1820 1680)
	  (1849 1725))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-2
	  (1120 1080 1820 1680)
	  (nil nil))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (1120 1080 1820 1680)
	  (x-set-frame-parameters 1))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> "FRAME-NOTICE-USER" nil
	  ((height . 56)
	   (width . 130)
	   (left . 0)
	   (top . 0)))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> "MAKE-FRAME")
 (#<frame emacs@rpluim-ubuntu 0x133fd20> x-handle-net-wm-state nil
	  (nil nil))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> x-handle-net-wm-state nil
	  (nil nil))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> x-handle-net-wm-state nil
	  (nil nil))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> x-handle-net-wm-state nil
	  (nil nil))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> x-handle-net-wm-state nil
	  (nil nil))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> xg-frame-resized
	  (1120 1080 1120 1080)
	  nil)
 (#<frame emacs@rpluim-ubuntu 0x133fd20> x-set-fullscreen nil
	  (nil nil))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (1120 1080 1120 1080)
	  (xg-frame-set-char-size 5))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> xg-frame-set-char-size-3
	  (1120 1080 1120 1080)
	  (1149 1125))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-2
	  (1120 1080 1120 1080)
	  (nil nil))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (1120 1080 1120 1080)
	  (x-create-frame-2 0))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (1120 1080 1120 1080)
	  (menu-bar-lines 2))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (1120 1080 1120 1080)
	  (scroll-bar-height 3))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-3
	  (1120 1080 1120 1080)
	  (1136 1080 1149 1080))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (1120 1080 1120 1080)
	  (scroll-bar-width 3))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-3
	  (10 10 140 300)
	  (10 10 156 300))
 (#<frame emacs@rpluim-ubuntu 0x133fd20> adjust-frame-size-1
	  (10 10 140 300)
	  (x-create-frame-1 5))
 (#<dead frame F1 0xc89040> adjust-frame-size-3
	 (10 10 10 9)
	 (10 10 10 10))
 (#<dead frame F1 0xc89040> adjust-frame-size-1
	 (10 10 10 9)
	 (change-frame-size 5)))

bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[martin rudalics]

 > 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

bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[Robert Pluim]

[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]

martin rudalics <rudalics@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


[-- Attachment #2: 31745.el --]
[-- Type: application/emacs-lisp, Size: 10997 bytes --]

bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[martin rudalics]

 > 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

bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[Robert Pluim]

martin rudalics <rudalics@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

bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[martin rudalics]

 >> 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

bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[Robert Pluim]

martin rudalics <rudalics@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

bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[martin rudalics]

 >> (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

bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[Robert Pluim]

[-- Attachment #1: Type: text/plain, Size: 2681 bytes --]

martin rudalics <rudalics@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:


[-- Attachment #2: Selection_029.png --]
[-- Type: image/png, Size: 16790 bytes --]

[-- Attachment #3: Type: text/plain, Size: 10 bytes --]



Robert

bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[martin rudalics]

 > 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

bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[Robert Pluim]

martin rudalics <rudalics@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

bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[martin rudalics]

 > 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

bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[Robert Pluim]

martin rudalics <rudalics@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

bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[martin rudalics]

 >>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

bug#31745: �ظ��� bug#31745: �ظ����ظ���Re: �ظ���bug#31745: Frame's bug whenwindow-system

[����]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 787 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 842 bytes --]

bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[Robert Pluim]

martin rudalics <rudalics@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

bug#31745: bug#31745: �ظ����ظ����ظ���Re: �ظ���bug#31745: Frame'sbug whenwindow-system

[����]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 86 bytes --]

I'm using MATE 1.20.0 with it's default window manager, Metacity (Marco) on Archlinux.

[-- Attachment #2: Type: text/html, Size: 90 bytes --]

bug#31745: default-frame-alist sizing parameters set in ~/.emacs are not applied correctly

[Lars Ingebrigtsen]

"" <mark.liu.li.ming@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

bug#31745: default-frame-alist sizing parameters set in ~/.emacs are not applied correctly

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@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#31745: �ظ��� bug#31745: �ظ��� bug#31745: �ظ����ظ���Re: �ظ���bug#31745: Frame's bug whenwindow-system

[����]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 4825 bytes --]

Follow is the trace resulting from `emacs`:



Frame size history of #<frame emacs@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@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@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@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)

[-- Attachment #2: Type: text/html, Size: 6857 bytes --]

bug#31745: 回复： bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[martin rudalics]

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

bug#31745: �ظ��� bug#31745: �ظ��� bug#31745: �ظ����ظ���Re: �ظ���bug#31745: Frame's bug whenwindow-system

[����]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 2251 bytes --]

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@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@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@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)

[-- Attachment #2: Type: text/html, Size: 3220 bytes --]

bug#31745: 回复： bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[martin rudalics]

 > 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

bug#31745: 回复： bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[Robert Pluim]

martin rudalics <rudalics@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