GNU bug report logs -
#46827
Broken initial size of GTK3 frame
Previous Next
Reported by: martin rudalics <rudalics <at> gmx.at>
Date: Sun, 28 Feb 2021 09:32:01 UTC
Severity: normal
Tags: fixed
Fixed in version 28.1
Done: martin rudalics <rudalics <at> gmx.at>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 46827 in the body.
You can then email your comments to 46827 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#46827; Package
emacs.
(Sun, 28 Feb 2021 09:32:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
martin rudalics <rudalics <at> gmx.at>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 28 Feb 2021 09:32:01 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)]
With a GTK3 build I start Emacs with the following initial file
contents:
(customize-set-variable
'default-frame-alist
'((cursor-color . "red3")
(width . 80)
(height . 32)))
Here this results in a frame that is 36 lines high, has a root window of
31 lines and a minibuffer window of 1 line. The remaining four lines at
the bottom of the frame are (more or less) empty.
I traced this behavior back to
Fix redisplay performance problems with some fonts
* src/font.c (font_list_entities): Revert part of the changes
introduced on Apr 2, 2014 to fix bug#17125. It turns out having
zero_vector in the font-cache is an important indication that
cannot be removed. (Bug#21028)
Commit f3b24e90dc9fad355102e1fdf2828ca33d447a07 does not have the bug
while commit 58430f29968a5661caff630d20dbbe7c864fe08d has it, see the
attached screenshots.
Reverting 58430f29968a5661caff630d20dbbe7c864fe08d with current master
does _not_ fix the bug, so something else must be at play here too.
This is with stable Debian running xfce 4.12 and xfwm4. I suppose that
various behaviors sketched in Bug#31745 might be related but I have no
idea how the font_list_entities fix could have affected frame creation
in the first place, so these are only wild speculations. As mentioned
there as well, the bug is GTK3-only, GTK2/Lucid/Motif/None builds are
not affected.
martin
[Initial Frame 58430f29968a5661caff630d20dbbe7c864fe08d.png (image/png, attachment)]
[Initial Frame f3b24e90dc9fad355102e1fdf2828ca33d447a07.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Sun, 28 Feb 2021 18:10:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Sun, 28 Feb 2021 10:31:30 +0100
>
> With a GTK3 build I start Emacs with the following initial file
> contents:
>
> (customize-set-variable
> 'default-frame-alist
> '((cursor-color . "red3")
> (width . 80)
> (height . 32)))
>
> Here this results in a frame that is 36 lines high, has a root window of
> 31 lines and a minibuffer window of 1 line. The remaining four lines at
> the bottom of the frame are (more or less) empty.
>
> I traced this behavior back to
>
> Fix redisplay performance problems with some fonts
> * src/font.c (font_list_entities): Revert part of the changes
> introduced on Apr 2, 2014 to fix bug#17125. It turns out having
> zero_vector in the font-cache is an important indication that
> cannot be removed. (Bug#21028)
This is very strange, that commit was not supposed to affect frame
dimensions.
Could you please step through the relevant frame-sizing code, and see
how that zero_vector entry in the font-cache causes this problem?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 01 Mar 2021 08:32:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 46827 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Re-sending this since it apparently got lost by the bug tracker:
> Reverting 58430f29968a5661caff630d20dbbe7c864fe08d with current master
> does _not_ fix the bug, so something else must be at play here too.
It turns out that the "something else" is just that
/* Querying further backends can be very slow, so we only do
it if the user has explicitly requested it (Bug#43177). */
if (query_all_font_backends == false)
break;
The attached patch reverting 58430f29968a5661caff630d20dbbe7c864fe08d
and removing the entity above fixes the bug on master.
martin
[font.c.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 01 Mar 2021 08:33:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> This is very strange, that commit was not supposed to affect frame
> dimensions.
>
> Could you please step through the relevant frame-sizing code, and see
> how that zero_vector entry in the font-cache causes this problem?
The bug seems to be caused by the part of the tool bar code that tries
to detect the height of the tool bar and resize the frame
correspondingly. Turning off the tool bar makes the bug disappear.
The font.c change garbles the order of the calls of frame resizing
routines. The following lines produced by `frame--size-history' are
from a "good" run (with the patch I posted earlier here applied)
FRAME-NOTICE-USER nil ((cursor-color . red3) (width . 80) (height . 32))
adjust-frame-size-1 (720 648 720 576) (x-set-frame-parameters 1)
adjust-frame-size-2 (720 648 720 576) (nil nil)
xg-frame-set-char-size-3 (720 648 720 576) (752 601)
xg-frame-resized (720 648 720 576) nil
adjust-frame-size-1 (720 648 720 576) (change-frame-size 5)
adjust-frame-size-3 (720 648 720 576) (752 648 752 576)
update-frame-tool-bar nil nil
adjust-frame-size-1 (720 576 720 576) (tool-bar-lines 2)
adjust-frame-size-2 (720 576 720 576) (nil nil)
xg-frame-set-char-size-3 (720 576 720 576) (752 642)
xg-frame-resized (720 576 720 576) nil
while these lines are from a "bad" run (one showing the bug)
FRAME-NOTICE-USER nil ((cursor-color . red3) (width . 80) (height . 32))
adjust-frame-size-1 (720 648 720 576) (x-set-frame-parameters 1)
adjust-frame-size-2 (720 648 720 576) (nil nil)
xg-frame-set-char-size-3 (720 648 720 576) (752 601)
xg-frame-resized (720 648 720 576) nil
update-frame-tool-bar nil nil
adjust-frame-size-1 (720 648 720 648) (tool-bar-lines 2)
adjust-frame-size-2 (720 648 720 648) (nil nil)
xg-frame-set-char-size-3 (720 648 720 648) (752 714)
xg-frame-resized (720 648 720 648) nil
adjust-frame-size-1 (720 648 720 576) (change-frame-size 5)
adjust-frame-size-3 (720 648 720 576) (752 648 752 576)
In the bad run, the `change-frame-size' call apparently gets delayed (by
a skipped 'do_pending_window_change' presumably) until after an
update_frame_tool_bar call gets there first. But so far I have no idea
why font cache issues would have any impact on the order of how things
get executed here.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 01 Mar 2021 09:47:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> But so far I have no idea
> why font cache issues would have any impact on the order of how things
> get executed here.
One clue I found is this: With a "good" run, update_frame_tool_bar gets
called three times with an existing FRAME_GTK_WIDGET, with a "bad" run
it gets called four times before the initial frame appears. The two
traces below are for Emacs 27 where the first, "good" one is without the
zero_vector assignment and the second, "bad" one is with it.
martin
WITHOUT zero_vector:
Thread 1 "emacs" hit Breakpoint 3, update_frame_tool_bar (f=0x1456d70) at ../../src/gtkutil.c:4948
4948 block_input ();
(gdb) bt
#0 0x0000000000621c5c in update_frame_tool_bar (f=0x1456d70) at ../../src/gtkutil.c:4948
#1 0x0000000000619fd7 in xg_create_frame_widgets (f=0x1456d70) at ../../src/gtkutil.c:1294
#2 0x00000000005e5607 in x_window (f=0x1456d70) at ../../src/xfns.c:3194
#3 0x00000000005e7eb1 in Fx_create_frame (parms=XIL(0x105e383)) at ../../src/xfns.c:4055
#4 0x00000000007b4852 in funcall_subr (subr=0xf8f0c0 <Sx_create_frame>, numargs=1, args=0x7fffffffb568) at ../../src/eval.c:2872
#5 0x00000000007b431c in Ffuncall (nargs=2, args=0x7fffffffb560) at ../../src/eval.c:2799
#6 0x0000000000837a9d in exec_byte_code (bytestr=XIL(0x7ffff3e3ee6c), vector=XIL(0x7ffff3e3df85), maxdepth=make_fixnum(13), args_template=make_fixnum(256), nargs=1, args=0x7fffffffba80) at ../../src/bytecode.c:633
#7 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff3e3df55), nargs=1, arg_vector=0x7fffffffba78) at ../../src/eval.c:2994
#8 0x00000000007b4360 in Ffuncall (nargs=2, args=0x7fffffffba70) at ../../src/eval.c:2801
#9 0x0000000000837a9d in exec_byte_code (bytestr=XIL(0x7ffff3e3eeac), vector=XIL(0x7ffff3e3df15), maxdepth=make_fixnum(3), args_template=make_fixnum(257), nargs=1, args=0x7fffffffc0a0) at ../../src/bytecode.c:633
#10 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff3e3dec5), nargs=1, arg_vector=0x7fffffffc098) at ../../src/eval.c:2994
#11 0x00000000007b4360 in Ffuncall (nargs=2, args=0x7fffffffc090) at ../../src/eval.c:2801
#12 0x00000000007b318e in Fapply (nargs=2, args=0x7fffffffc090) at ../../src/eval.c:2386
#13 0x00000000007b4746 in funcall_subr (subr=0xf97cc0 <Sapply>, numargs=2, args=0x7fffffffc090) at ../../src/eval.c:2852
#14 0x00000000007b431c in Ffuncall (nargs=3, args=0x7fffffffc088) at ../../src/eval.c:2799
#15 0x0000000000837a9d in exec_byte_code (bytestr=XIL(0x7ffff3cfbc7c), vector=XIL(0x7ffff3e3ba7d), maxdepth=make_fixnum(15), args_template=make_fixnum(128), nargs=1, args=0x7fffffffc5c8) at ../../src/bytecode.c:633
#16 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff3e3ba4d), nargs=1, arg_vector=0x7fffffffc5c8) at ../../src/eval.c:2994
#17 0x00000000007b4360 in Ffuncall (nargs=2, args=0x7fffffffc5c0) at ../../src/eval.c:2801
#18 0x0000000000837a9d in exec_byte_code (bytestr=XIL(0x7ffff3e4e5cc), vector=XIL(0x7ffff3c1f21d), maxdepth=make_fixnum(14), args_template=make_fixnum(256), nargs=1, args=0x7fffffffcba8) at ../../src/bytecode.c:633
#19 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff3c1f1e5), nargs=1, arg_vector=0x7fffffffcba0) at ../../src/eval.c:2994
#20 0x00000000007b4360 in Ffuncall (nargs=2, args=0x7fffffffcb98) at ../../src/eval.c:2801
#21 0x0000000000837a9d in exec_byte_code (bytestr=XIL(0x7ffff400baa4), vector=XIL(0x7ffff400b9fd), maxdepth=make_fixnum(6), args_template=make_fixnum(0), nargs=0, args=0x7fffffffd090) at ../../src/bytecode.c:633
#22 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff400b9cd), nargs=0, arg_vector=0x7fffffffd090) at ../../src/eval.c:2994
#23 0x00000000007b4360 in Ffuncall (nargs=1, args=0x7fffffffd088) at ../../src/eval.c:2801
#24 0x0000000000837a9d in exec_byte_code (bytestr=XIL(0x7ffff4011b5c), vector=XIL(0x7ffff400dbdd), maxdepth=make_fixnum(14), args_template=make_fixnum(0), nargs=0, args=0x7fffffffdbd8) at ../../src/bytecode.c:633
#25 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff400dbad), nargs=0, arg_vector=0x7fffffffdbd8) at ../../src/eval.c:2994
#26 0x00000000007b4360 in Ffuncall (nargs=1, args=0x7fffffffdbd0) at ../../src/eval.c:2801
#27 0x0000000000837a9d in exec_byte_code (bytestr=XIL(0x7ffff401282c), vector=XIL(0x7ffff4011d2d), maxdepth=make_fixnum(12), args_template=make_fixnum(0), nargs=0, args=0x7fffffffe220) at ../../src/bytecode.c:633
#28 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff4011cfd), nargs=0, arg_vector=0x7fffffffe220) at ../../src/eval.c:2994
#29 0x00000000007b4bd7 in apply_lambda (fun=XIL(0x7ffff4011cfd), args=XIL(0), count=4) at ../../src/eval.c:2931
#30 0x00000000007b2dd3 in eval_sub (form=XIL(0x7ffff416d89b)) at ../../src/eval.c:2323
#31 0x00000000007b2163 in Feval (form=XIL(0x7ffff416d89b), lexical=XIL(0)) at ../../src/eval.c:2107
#32 0x000000000064af57 in top_level_2 () at ../../src/keyboard.c:1100
#33 0x00000000007b0300 in internal_condition_case (bfun=0x64af34 <top_level_2>, handlers=XIL(0x90), hfun=0x64a933 <cmd_error>) at ../../src/eval.c:1360
#34 0x000000000064af9f in top_level_1 (ignore=XIL(0)) at ../../src/keyboard.c:1108
#35 0x00000000007af7b4 in internal_catch (tag=XIL(0xd110), func=0x64af59 <top_level_1>, arg=XIL(0)) at ../../src/eval.c:1121
#36 0x000000000064ae7e in command_loop () at ../../src/keyboard.c:1069
#37 0x000000000064a41a in recursive_edit_1 () at ../../src/keyboard.c:714
#38 0x000000000064a612 in Frecursive_edit () at ../../src/keyboard.c:786
#39 0x0000000000640a1b in main (argc=4, argv=0x7fffffffe798) at ../../src/emacs.c:2066
Lisp Backtrace:
"x-create-frame" (0xffffb568)
"x-create-frame-with-faces" (0xffffba78)
0xf3e3dec0 PVEC_COMPILED
"apply" (0xffffc090)
"frame-creation-function" (0xffffc5c8)
"make-frame" (0xffffcba0)
"frame-initialize" (0xffffd090)
"command-line" (0xffffdbd8)
"normal-top-level" (0xffffe220)
(gdb) c
Continuing.
[Switching to thread 4 (Thread 0x7ffff1c7e700 (LWP 10050))](running)
Thread 1 "emacs" hit Breakpoint 3, update_frame_tool_bar (f=0x1456d70) at ../../src/gtkutil.c:4948
4948 block_input ();
(gdb) bt
#0 0x0000000000621c5c in update_frame_tool_bar (f=0x1456d70) at ../../src/gtkutil.c:4948
#1 0x000000000048748f in redisplay_tool_bar (f=0x1456d70) at ../../src/xdisp.c:14161
#2 0x000000000049686c in redisplay_window (window=XIL(0x14bf815), just_this_one_p=false) at ../../src/xdisp.c:19074
#3 0x000000000048beeb in redisplay_window_0 (window=XIL(0x14bf815)) at ../../src/xdisp.c:16328
#4 0x00000000007b03db in internal_condition_case_1 (bfun=0x48bea9 <redisplay_window_0>, arg=XIL(0x14bf815), handlers=XIL(0x7ffff3e9921b), hfun=0x48be71 <redisplay_window_error>) at ../../src/eval.c:1384
#5 0x000000000048be43 in redisplay_windows (window=XIL(0x14bf815)) at ../../src/xdisp.c:16308
#6 0x000000000048bdf5 in redisplay_windows (window=XIL(0x134be45)) at ../../src/xdisp.c:16302
#7 0x000000000048a871 in redisplay_internal () at ../../src/xdisp.c:15776
#8 0x0000000000488458 in redisplay () at ../../src/xdisp.c:14998
#9 0x000000000064f2da in read_char (commandflag=1, map=XIL(0x18b5833), prev_event=XIL(0), used_mouse_menu=0x7fffffffe10f, end_time=0x0) at ../../src/keyboard.c:2493
#10 0x000000000066221b in read_key_sequence (keybuf=0x7fffffffe2a0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../src/keyboard.c:9554
#11 0x000000000064b7a0 in command_loop_1 () at ../../src/keyboard.c:1350
#12 0x00000000007b0300 in internal_condition_case (bfun=0x64b324 <command_loop_1>, handlers=XIL(0x90), hfun=0x64a933 <cmd_error>) at ../../src/eval.c:1360
#13 0x000000000064af09 in command_loop_2 (ignore=XIL(0)) at ../../src/keyboard.c:1091
#14 0x00000000007af7b4 in internal_catch (tag=XIL(0xd110), func=0x64aedc <command_loop_2>, arg=XIL(0)) at ../../src/eval.c:1121
#15 0x000000000064aea7 in command_loop () at ../../src/keyboard.c:1070
#16 0x000000000064a41a in recursive_edit_1 () at ../../src/keyboard.c:714
#17 0x000000000064a612 in Frecursive_edit () at ../../src/keyboard.c:786
#18 0x0000000000640a1b in main (argc=4, argv=0x7fffffffe798) at ../../src/emacs.c:2066
Lisp Backtrace:
"redisplay_internal (C function)" (0x0)
(gdb) c
Continuing.
[Switching to thread 4 (Thread 0x7ffff1c7e700 (LWP 10050))](running)
Thread 1 "emacs" hit Breakpoint 3, update_frame_tool_bar (f=0x1456d70) at ../../src/gtkutil.c:4948
4948 block_input ();
(gdb) bt
#0 0x0000000000621c5c in update_frame_tool_bar (f=0x1456d70) at ../../src/gtkutil.c:4948
#1 0x000000000048748f in redisplay_tool_bar (f=0x1456d70) at ../../src/xdisp.c:14161
#2 0x000000000049686c in redisplay_window (window=XIL(0x14bf815), just_this_one_p=false) at ../../src/xdisp.c:19074
#3 0x000000000048beeb in redisplay_window_0 (window=XIL(0x14bf815)) at ../../src/xdisp.c:16328
#4 0x00000000007b03db in internal_condition_case_1 (bfun=0x48bea9 <redisplay_window_0>, arg=XIL(0x14bf815), handlers=XIL(0x7ffff3e9921b), hfun=0x48be71 <redisplay_window_error>) at ../../src/eval.c:1384
#5 0x000000000048be43 in redisplay_windows (window=XIL(0x14bf815)) at ../../src/xdisp.c:16308
#6 0x000000000048bdf5 in redisplay_windows (window=XIL(0x134be45)) at ../../src/xdisp.c:16302
#7 0x000000000048a871 in redisplay_internal () at ../../src/xdisp.c:15776
#8 0x0000000000488458 in redisplay () at ../../src/xdisp.c:14998
#9 0x000000000064f2da in read_char (commandflag=1, map=XIL(0x18b5833), prev_event=XIL(0), used_mouse_menu=0x7fffffffe10f, end_time=0x0) at ../../src/keyboard.c:2493
#10 0x000000000066221b in read_key_sequence (keybuf=0x7fffffffe2a0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../src/keyboard.c:9554
#11 0x000000000064b7a0 in command_loop_1 () at ../../src/keyboard.c:1350
#12 0x00000000007b0300 in internal_condition_case (bfun=0x64b324 <command_loop_1>, handlers=XIL(0x90), hfun=0x64a933 <cmd_error>) at ../../src/eval.c:1360
#13 0x000000000064af09 in command_loop_2 (ignore=XIL(0)) at ../../src/keyboard.c:1091
#14 0x00000000007af7b4 in internal_catch (tag=XIL(0xd110), func=0x64aedc <command_loop_2>, arg=XIL(0)) at ../../src/eval.c:1121
#15 0x000000000064aea7 in command_loop () at ../../src/keyboard.c:1070
#16 0x000000000064a41a in recursive_edit_1 () at ../../src/keyboard.c:714
#17 0x000000000064a612 in Frecursive_edit () at ../../src/keyboard.c:786
#18 0x0000000000640a1b in main (argc=4, argv=0x7fffffffe798) at ../../src/emacs.c:2066
Lisp Backtrace:
"redisplay_internal (C function)" (0x0)
(gdb) c
Continuing.
[Switching to thread 4 (Thread 0x7ffff1c7e700 (LWP 10050))](running)
WITH zero_vector:
Thread 1 "emacs" hit Breakpoint 3, update_frame_tool_bar (f=0x14369f0) at ../../src/gtkutil.c:4948
4948 block_input ();
(gdb) bt
#0 0x0000000000621c5c in update_frame_tool_bar (f=0x14369f0) at ../../src/gtkutil.c:4948
#1 0x0000000000619fd7 in xg_create_frame_widgets (f=0x14369f0) at ../../src/gtkutil.c:1294
#2 0x00000000005e5607 in x_window (f=0x14369f0) at ../../src/xfns.c:3194
#3 0x00000000005e7eb1 in Fx_create_frame (parms=XIL(0x105e383)) at ../../src/xfns.c:4055
#4 0x00000000007b4852 in funcall_subr (subr=0xf8f0c0 <Sx_create_frame>, numargs=1, args=0x7fffffffb568) at ../../src/eval.c:2872
#5 0x00000000007b431c in Ffuncall (nargs=2, args=0x7fffffffb560) at ../../src/eval.c:2799
#6 0x0000000000837a86 in exec_byte_code (bytestr=XIL(0x7ffff3e3ee6c), vector=XIL(0x7ffff3e3df85), maxdepth=make_fixnum(13), args_template=make_fixnum(256), nargs=1, args=0x7fffffffba80) at ../../src/bytecode.c:633
#7 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff3e3df55), nargs=1, arg_vector=0x7fffffffba78) at ../../src/eval.c:2994
#8 0x00000000007b4360 in Ffuncall (nargs=2, args=0x7fffffffba70) at ../../src/eval.c:2801
#9 0x0000000000837a86 in exec_byte_code (bytestr=XIL(0x7ffff3e3eeac), vector=XIL(0x7ffff3e3df15), maxdepth=make_fixnum(3), args_template=make_fixnum(257), nargs=1, args=0x7fffffffc0a0) at ../../src/bytecode.c:633
#10 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff3e3dec5), nargs=1, arg_vector=0x7fffffffc098) at ../../src/eval.c:2994
#11 0x00000000007b4360 in Ffuncall (nargs=2, args=0x7fffffffc090) at ../../src/eval.c:2801
#12 0x00000000007b318e in Fapply (nargs=2, args=0x7fffffffc090) at ../../src/eval.c:2386
#13 0x00000000007b4746 in funcall_subr (subr=0xf97cc0 <Sapply>, numargs=2, args=0x7fffffffc090) at ../../src/eval.c:2852
#14 0x00000000007b431c in Ffuncall (nargs=3, args=0x7fffffffc088) at ../../src/eval.c:2799
#15 0x0000000000837a86 in exec_byte_code (bytestr=XIL(0x7ffff3cfbc7c), vector=XIL(0x7ffff3e3ba7d), maxdepth=make_fixnum(15), args_template=make_fixnum(128), nargs=1, args=0x7fffffffc5c8) at ../../src/bytecode.c:633
#16 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff3e3ba4d), nargs=1, arg_vector=0x7fffffffc5c8) at ../../src/eval.c:2994
#17 0x00000000007b4360 in Ffuncall (nargs=2, args=0x7fffffffc5c0) at ../../src/eval.c:2801
#18 0x0000000000837a86 in exec_byte_code (bytestr=XIL(0x7ffff3e4e5cc), vector=XIL(0x7ffff3c1f21d), maxdepth=make_fixnum(14), args_template=make_fixnum(256), nargs=1, args=0x7fffffffcba8) at ../../src/bytecode.c:633
#19 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff3c1f1e5), nargs=1, arg_vector=0x7fffffffcba0) at ../../src/eval.c:2994
#20 0x00000000007b4360 in Ffuncall (nargs=2, args=0x7fffffffcb98) at ../../src/eval.c:2801
#21 0x0000000000837a86 in exec_byte_code (bytestr=XIL(0x7ffff400baa4), vector=XIL(0x7ffff400b9fd), maxdepth=make_fixnum(6), args_template=make_fixnum(0), nargs=0, args=0x7fffffffd090) at ../../src/bytecode.c:633
#22 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff400b9cd), nargs=0, arg_vector=0x7fffffffd090) at ../../src/eval.c:2994
#23 0x00000000007b4360 in Ffuncall (nargs=1, args=0x7fffffffd088) at ../../src/eval.c:2801
#24 0x0000000000837a86 in exec_byte_code (bytestr=XIL(0x7ffff4011b5c), vector=XIL(0x7ffff400dbdd), maxdepth=make_fixnum(14), args_template=make_fixnum(0), nargs=0, args=0x7fffffffdbd8) at ../../src/bytecode.c:633
#25 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff400dbad), nargs=0, arg_vector=0x7fffffffdbd8) at ../../src/eval.c:2994
#26 0x00000000007b4360 in Ffuncall (nargs=1, args=0x7fffffffdbd0) at ../../src/eval.c:2801
#27 0x0000000000837a86 in exec_byte_code (bytestr=XIL(0x7ffff401282c), vector=XIL(0x7ffff4011d2d), maxdepth=make_fixnum(12), args_template=make_fixnum(0), nargs=0, args=0x7fffffffe220) at ../../src/bytecode.c:633
#28 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff4011cfd), nargs=0, arg_vector=0x7fffffffe220) at ../../src/eval.c:2994
#29 0x00000000007b4bd7 in apply_lambda (fun=XIL(0x7ffff4011cfd), args=XIL(0), count=4) at ../../src/eval.c:2931
#30 0x00000000007b2dd3 in eval_sub (form=XIL(0x7ffff416d89b)) at ../../src/eval.c:2323
#31 0x00000000007b2163 in Feval (form=XIL(0x7ffff416d89b), lexical=XIL(0)) at ../../src/eval.c:2107
#32 0x000000000064af57 in top_level_2 () at ../../src/keyboard.c:1100
#33 0x00000000007b0300 in internal_condition_case (bfun=0x64af34 <top_level_2>, handlers=XIL(0x90), hfun=0x64a933 <cmd_error>) at ../../src/eval.c:1360
#34 0x000000000064af9f in top_level_1 (ignore=XIL(0)) at ../../src/keyboard.c:1108
#35 0x00000000007af7b4 in internal_catch (tag=XIL(0xd110), func=0x64af59 <top_level_1>, arg=XIL(0)) at ../../src/eval.c:1121
#36 0x000000000064ae7e in command_loop () at ../../src/keyboard.c:1069
#37 0x000000000064a41a in recursive_edit_1 () at ../../src/keyboard.c:714
#38 0x000000000064a612 in Frecursive_edit () at ../../src/keyboard.c:786
#39 0x0000000000640a1b in main (argc=4, argv=0x7fffffffe798) at ../../src/emacs.c:2066
Lisp Backtrace:
"x-create-frame" (0xffffb568)
"x-create-frame-with-faces" (0xffffba78)
0xf3e3dec0 PVEC_COMPILED
"apply" (0xffffc090)
"frame-creation-function" (0xffffc5c8)
"make-frame" (0xffffcba0)
"frame-initialize" (0xffffd090)
"command-line" (0xffffdbd8)
"normal-top-level" (0xffffe220)
(gdb) c
Continuing.
[Switching to thread 4 (Thread 0x7ffff1c5d700 (LWP 10301))](running)
Thread 1 "emacs" hit Breakpoint 3, update_frame_tool_bar (f=0x14369f0) at ../../src/gtkutil.c:4948
4948 block_input ();
(gdb) bt
#0 0x0000000000621c5c in update_frame_tool_bar (f=0x14369f0) at ../../src/gtkutil.c:4948
#1 0x000000000048748f in redisplay_tool_bar (f=0x14369f0) at ../../src/xdisp.c:14161
#2 0x000000000049686c in redisplay_window (window=XIL(0x149feb5), just_this_one_p=false) at ../../src/xdisp.c:19074
#3 0x000000000048beeb in redisplay_window_0 (window=XIL(0x149feb5)) at ../../src/xdisp.c:16328
#4 0x00000000007b03db in internal_condition_case_1 (bfun=0x48bea9 <redisplay_window_0>, arg=XIL(0x149feb5), handlers=XIL(0x7ffff3e9921b), hfun=0x48be71 <redisplay_window_error>) at ../../src/eval.c:1384
#5 0x000000000048be43 in redisplay_windows (window=XIL(0x149feb5)) at ../../src/xdisp.c:16308
#6 0x000000000048bdf5 in redisplay_windows (window=XIL(0x135ee55)) at ../../src/xdisp.c:16302
#7 0x000000000048a871 in redisplay_internal () at ../../src/xdisp.c:15776
#8 0x0000000000488458 in redisplay () at ../../src/xdisp.c:14998
#9 0x000000000064f2da in read_char (commandflag=1, map=XIL(0x1897353), prev_event=XIL(0), used_mouse_menu=0x7fffffffe10f, end_time=0x0) at ../../src/keyboard.c:2493
#10 0x000000000066221b in read_key_sequence (keybuf=0x7fffffffe2a0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../src/keyboard.c:9554
#11 0x000000000064b7a0 in command_loop_1 () at ../../src/keyboard.c:1350
#12 0x00000000007b0300 in internal_condition_case (bfun=0x64b324 <command_loop_1>, handlers=XIL(0x90), hfun=0x64a933 <cmd_error>) at ../../src/eval.c:1360
#13 0x000000000064af09 in command_loop_2 (ignore=XIL(0)) at ../../src/keyboard.c:1091
#14 0x00000000007af7b4 in internal_catch (tag=XIL(0xd110), func=0x64aedc <command_loop_2>, arg=XIL(0)) at ../../src/eval.c:1121
#15 0x000000000064aea7 in command_loop () at ../../src/keyboard.c:1070
#16 0x000000000064a41a in recursive_edit_1 () at ../../src/keyboard.c:714
#17 0x000000000064a612 in Frecursive_edit () at ../../src/keyboard.c:786
#18 0x0000000000640a1b in main (argc=4, argv=0x7fffffffe798) at ../../src/emacs.c:2066
Lisp Backtrace:
"redisplay_internal (C function)" (0x0)
(gdb) c
Continuing.
[Switching to thread 4 (Thread 0x7ffff1c5d700 (LWP 10301))](running)
Thread 1 "emacs" hit Breakpoint 3, update_frame_tool_bar (f=0x14369f0) at ../../src/gtkutil.c:4948
4948 block_input ();
(gdb) bt
#0 0x0000000000621c5c in update_frame_tool_bar (f=0x14369f0) at ../../src/gtkutil.c:4948
#1 0x000000000048748f in redisplay_tool_bar (f=0x14369f0) at ../../src/xdisp.c:14161
#2 0x000000000049686c in redisplay_window (window=XIL(0x149feb5), just_this_one_p=false) at ../../src/xdisp.c:19074
#3 0x000000000048beeb in redisplay_window_0 (window=XIL(0x149feb5)) at ../../src/xdisp.c:16328
#4 0x00000000007b03db in internal_condition_case_1 (bfun=0x48bea9 <redisplay_window_0>, arg=XIL(0x149feb5), handlers=XIL(0x7ffff3e9921b), hfun=0x48be71 <redisplay_window_error>) at ../../src/eval.c:1384
#5 0x000000000048be43 in redisplay_windows (window=XIL(0x149feb5)) at ../../src/xdisp.c:16308
#6 0x000000000048bdf5 in redisplay_windows (window=XIL(0x135ee55)) at ../../src/xdisp.c:16302
#7 0x000000000048a871 in redisplay_internal () at ../../src/xdisp.c:15776
#8 0x0000000000488458 in redisplay () at ../../src/xdisp.c:14998
#9 0x000000000064f2da in read_char (commandflag=1, map=XIL(0x1897353), prev_event=XIL(0), used_mouse_menu=0x7fffffffe10f, end_time=0x0) at ../../src/keyboard.c:2493
#10 0x000000000066221b in read_key_sequence (keybuf=0x7fffffffe2a0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../src/keyboard.c:9554
#11 0x000000000064b7a0 in command_loop_1 () at ../../src/keyboard.c:1350
#12 0x00000000007b0300 in internal_condition_case (bfun=0x64b324 <command_loop_1>, handlers=XIL(0x90), hfun=0x64a933 <cmd_error>) at ../../src/eval.c:1360
#13 0x000000000064af09 in command_loop_2 (ignore=XIL(0)) at ../../src/keyboard.c:1091
#14 0x00000000007af7b4 in internal_catch (tag=XIL(0xd110), func=0x64aedc <command_loop_2>, arg=XIL(0)) at ../../src/eval.c:1121
#15 0x000000000064aea7 in command_loop () at ../../src/keyboard.c:1070
#16 0x000000000064a41a in recursive_edit_1 () at ../../src/keyboard.c:714
#17 0x000000000064a612 in Frecursive_edit () at ../../src/keyboard.c:786
#18 0x0000000000640a1b in main (argc=4, argv=0x7fffffffe798) at ../../src/emacs.c:2066
Lisp Backtrace:
"redisplay_internal (C function)" (0x0)
(gdb) c
Continuing.
[Switching to thread 4 (Thread 0x7ffff1c5d700 (LWP 10301))](running)
Thread 1 "emacs" hit Breakpoint 3, update_frame_tool_bar (f=0x14369f0) at ../../src/gtkutil.c:4948
4948 block_input ();
(gdb) bt
#0 0x0000000000621c5c in update_frame_tool_bar (f=0x14369f0) at ../../src/gtkutil.c:4948
#1 0x000000000048748f in redisplay_tool_bar (f=0x14369f0) at ../../src/xdisp.c:14161
#2 0x000000000049686c in redisplay_window (window=XIL(0x149feb5), just_this_one_p=false) at ../../src/xdisp.c:19074
#3 0x000000000048beeb in redisplay_window_0 (window=XIL(0x149feb5)) at ../../src/xdisp.c:16328
#4 0x00000000007b03db in internal_condition_case_1 (bfun=0x48bea9 <redisplay_window_0>, arg=XIL(0x149feb5), handlers=XIL(0x7ffff3e9921b), hfun=0x48be71 <redisplay_window_error>) at ../../src/eval.c:1384
#5 0x000000000048be43 in redisplay_windows (window=XIL(0x149feb5)) at ../../src/xdisp.c:16308
#6 0x000000000048bdf5 in redisplay_windows (window=XIL(0x135ee55)) at ../../src/xdisp.c:16302
#7 0x000000000048a871 in redisplay_internal () at ../../src/xdisp.c:15776
#8 0x0000000000488458 in redisplay () at ../../src/xdisp.c:14998
#9 0x000000000064f2da in read_char (commandflag=1, map=XIL(0x1897353), prev_event=XIL(0), used_mouse_menu=0x7fffffffe10f, end_time=0x0) at ../../src/keyboard.c:2493
#10 0x000000000066221b in read_key_sequence (keybuf=0x7fffffffe2a0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../src/keyboard.c:9554
#11 0x000000000064b7a0 in command_loop_1 () at ../../src/keyboard.c:1350
#12 0x00000000007b0300 in internal_condition_case (bfun=0x64b324 <command_loop_1>, handlers=XIL(0x90), hfun=0x64a933 <cmd_error>) at ../../src/eval.c:1360
#13 0x000000000064af09 in command_loop_2 (ignore=XIL(0)) at ../../src/keyboard.c:1091
#14 0x00000000007af7b4 in internal_catch (tag=XIL(0xd110), func=0x64aedc <command_loop_2>, arg=XIL(0)) at ../../src/eval.c:1121
#15 0x000000000064aea7 in command_loop () at ../../src/keyboard.c:1070
#16 0x000000000064a41a in recursive_edit_1 () at ../../src/keyboard.c:714
#17 0x000000000064a612 in Frecursive_edit () at ../../src/keyboard.c:786
#18 0x0000000000640a1b in main (argc=4, argv=0x7fffffffe798) at ../../src/emacs.c:2066
Lisp Backtrace:
"redisplay_internal (C function)" (0x0)
(gdb) c
Continuing.
[Switching to thread 4 (Thread 0x7ffff1c5d700 (LWP 10301))](running)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 01 Mar 2021 10:16:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 1 Mar 2021 09:31:20 +0100, martin rudalics <rudalics <at> gmx.at> said:
martin> Re-sending this since it apparently got lost by the bug tracker:
>> Reverting 58430f29968a5661caff630d20dbbe7c864fe08d with current master
>> does _not_ fix the bug, so something else must be at play here too.
Iʼll just say I donʼt see this with Gnome on Debian testing, with
either emacs-27 or master, so once again itʼs window manager
dependent.
martin> It turns out that the "something else" is just that
martin> /* Querying further backends can be very slow, so we only do
martin> it if the user has explicitly requested it (Bug#43177). */
martin> if (query_all_font_backends == false)
martin> break;
martin> The attached patch reverting 58430f29968a5661caff630d20dbbe7c864fe08d
martin> and removing the entity above fixes the bug on master.
Iʼm surprised that querying another font backend when we've already
found a font causes frame sizing issues like this. Do we understand
the cause here?
We can revert the bug#43177 fix of course, but perhaps we should make
it conditional on !GTK3 || PGTK or something?
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 01 Mar 2021 12:40:03 GMT)
Full text and
rfc822 format available.
Message #23 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> Iʼll just say I donʼt see this with Gnome on Debian testing, with
> either emacs-27 or master, so once again itʼs window manager
> dependent.
What does (frame-height) give for your frame?
> Iʼm surprised that querying another font backend when we've already
> found a font causes frame sizing issues like this. Do we understand
> the cause here?
No. All I can say is that it is tool bar related.
> We can revert the bug#43177 fix of course, but perhaps we should make
> it conditional on !GTK3 || PGTK or something?
First I'd like to fix the behavior for Emacs 27, conceptually at least.
Then we can discuss Bug#43177.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 01 Mar 2021 13:32:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 1 Mar 2021 13:38:58 +0100, martin rudalics <rudalics <at> gmx.at> said:
>> Iʼll just say I donʼt see this with Gnome on Debian testing, with
>> either emacs-27 or master, so once again itʼs window manager
>> dependent.
martin> What does (frame-height) give for your frame?
30. A lucid build gives me 31, so itʼs no better. (all emacs-27)
Iʼll install xfwm4 and see what happens.
>> Iʼm surprised that querying another font backend when we've already
>> found a font causes frame sizing issues like this. Do we understand
>> the cause here?
martin> No. All I can say is that it is tool bar related.
<wild stab in the dark> What happens if you disable the code that
displays text labels in the tool bar:
diff --git a/src/gtkutil.c b/src/gtkutil.c
index 825fbe1d45..425b0727e9 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -4708,8 +4708,6 @@ xg_make_tool_item (struct frame *f,
if (wimage && !text_image)
gtk_box_pack_start (GTK_BOX (vb), wimage, TRUE, TRUE, 0);
- if (label)
- gtk_box_pack_start (GTK_BOX (vb), gtk_label_new (label), TRUE, TRUE, 0);
if (wimage && text_image)
gtk_box_pack_start (GTK_BOX (vb), wimage, TRUE, TRUE, 0);
@@ -4723,7 +4721,7 @@ xg_make_tool_item (struct frame *f,
gtk_container_add (GTK_CONTAINER (weventbox), wb);
gtk_container_add (GTK_CONTAINER (ti), weventbox);
- if (wimage || label)
+ if (wimage)
{
intptr_t ii = i;
gpointer gi = (gpointer) ii;
>> We can revert the bug#43177 fix of course, but perhaps we should make
>> it conditional on !GTK3 || PGTK or something?
martin> First I'd like to fix the behavior for Emacs 27, conceptually at least.
martin> Then we can discuss Bug#43177.
Works for me.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 01 Mar 2021 13:54:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 01 Mar 2021 14:30:58 +0100, Robert Pluim <rpluim <at> gmail.com> said:
>>>>> On Mon, 1 Mar 2021 13:38:58 +0100, martin rudalics <rudalics <at> gmx.at> said:
>>> Iʼll just say I donʼt see this with Gnome on Debian testing, with
>>> either emacs-27 or master, so once again itʼs window manager
>>> dependent.
martin> What does (frame-height) give for your frame?
Robert> 30. A lucid build gives me 31, so itʼs no better. (all emacs-27)
Robert> Iʼll install xfwm4 and see what happens.
With "xfwm4/testing,now 4.16.1-1 amd64" I donʼt see any issues with
the frame (and it gives me a frame height of 32).
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 01 Mar 2021 14:09:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Mon, 1 Mar 2021 09:31:20 +0100
>
> It turns out that the "something else" is just that
>
> /* Querying further backends can be very slow, so we only do
> it if the user has explicitly requested it (Bug#43177). */
> if (query_all_font_backends == false)
> break;
>
> The attached patch reverting 58430f29968a5661caff630d20dbbe7c864fe08d
> and removing the entity above fixes the bug on master.
Thanks, but removing the zero_vector entity is a non-starter. We paid
dearly for that change, so I don't want to get that problem back
again.
The other change is also quite important.
We need to find a better way of fixing this problem.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 01 Mar 2021 18:04:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> 30. A lucid build gives me 31, so itʼs no better. (all emacs-27)
Here only GTK3 builds are affected. Back then it took me months to get
these right. So the values you report above are quite annoying. Maybe
someone else could try ...
> <wild stab in the dark> What happens if you disable the code that
> displays text labels in the tool bar:
I thought about that too but it doesn't help.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 01 Mar 2021 18:04:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> With "xfwm4/testing,now 4.16.1-1 amd64" I donʼt see any issues with
> the frame (and it gives me a frame height of 32).
Hmm... interesting. Which GTK version is this? And what about the
other builds?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 01 Mar 2021 18:05:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>> The attached patch reverting 58430f29968a5661caff630d20dbbe7c864fe08d
>> and removing the entity above fixes the bug on master.
>
> Thanks, but removing the zero_vector entity is a non-starter. We paid
> dearly for that change, so I don't want to get that problem back
> again.
>
> The other change is also quite important.
>
> We need to find a better way of fixing this problem.
Agreed to both. I'd just have to understand first how the above can
and do affect redisplay.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 01 Mar 2021 18:24:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 1 Mar 2021 19:03:44 +0100, martin rudalics <rudalics <at> gmx.at> said:
>> With "xfwm4/testing,now 4.16.1-1 amd64" I donʼt see any issues with
>> the frame (and it gives me a frame height of 32).
martin> Hmm... interesting. Which GTK version is this? And what about the
martin> other builds?
3.24.24. The lucid build gives me a frame height of 32 as well.
Interestingly, if I run the gtk build under xfwm4 without its dumpfile
present, I do sometimes see the frame issue you reported, which
suggests itʼs a timing issue somewhere.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 01 Mar 2021 18:33:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 01 Mar 2021 19:23:21 +0100, Robert Pluim <rpluim <at> gmail.com> said:
>>>>> On Mon, 1 Mar 2021 19:03:44 +0100, martin rudalics <rudalics <at> gmx.at> said:
>>> With "xfwm4/testing,now 4.16.1-1 amd64" I donʼt see any issues with
>>> the frame (and it gives me a frame height of 32).
martin> Hmm... interesting. Which GTK version is this? And what about the
martin> other builds?
Robert> 3.24.24. The lucid build gives me a frame height of 32 as well.
Robert> Interestingly, if I run the gtk build under xfwm4 without its dumpfile
Robert> present, I do sometimes see the frame issue you reported, which
Robert> suggests itʼs a timing issue somewhere.
And in fact even with the dumpfile I see this in emacs-27 and
emacs-master, just not consistently.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 01 Mar 2021 19:05:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> Interestingly, if I run the gtk build under xfwm4 without its dumpfile
> present, I do sometimes see the frame issue you reported, which
> suggests itʼs a timing issue somewhere.
How do you run a build without the dump file present?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 01 Mar 2021 19:06:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> And in fact even with the dumpfile I see this in emacs-27 and
> emacs-master, just not consistently.
I see it consistently here and the same with GNOME 3.34.2. But the same
GTK3 build works correctly here with plasma 5.17.5 which, OTOH, makes my
Lucid frame only 31 lines high.
So we could dismiss the frame height differences as WM idiosyncrasies as
you said but that unhandled space at the bottom is too ugly.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 01 Mar 2021 19:50:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 46827 <at> debbugs.gnu.org (full text, mbox):
On Mon, 01 Mar 2021 19:23:21 +0100 Robert Pluim <rpluim <at> gmail.com> wrote:
>>>>>> On Mon, 1 Mar 2021 19:03:44 +0100, martin rudalics <rudalics <at> gmx.at> said:
>
> >> With "xfwm4/testing,now 4.16.1-1 amd64" I donʼt see any issues with
> >> the frame (and it gives me a frame height of 32).
>
> martin> Hmm... interesting. Which GTK version is this? And what about the
> martin> other builds?
>
> 3.24.24. The lucid build gives me a frame height of 32 as well.
>
> Interestingly, if I run the gtk build under xfwm4 without its dumpfile
> present, I do sometimes see the frame issue you reported, which
> suggests itʼs a timing issue somewhere.
Evidence in favor of that suggestion may be the following observations:
I can reliably reproduce the problematic display (on xfwm4-4.14.1 with
GTK+ 3.24.17) with the first invocation below, but not with the second
invocation:
$ emacs-master -Q --eval "(customize-set-variable 'default-frame-alist '((cursor-color . \"red3\") (width . 80) (height . 32)))"
$ emacs-master -Q --eval "(progn (sleep-for .1) (customize-set-variable 'default-frame-alist '((cursor-color . \"red3\") (width . 80) (height . 32))))"
Yet I can also reproduce the display problem with the following
invocation:
$ emacs-master -Q --eval "(progn (sit-for .1) (customize-set-variable 'default-frame-alist '((cursor-color . \"red3\") (width . 80) (height . 32))))"
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 01 Mar 2021 20:01:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 1 Mar 2021 20:04:47 +0100, martin rudalics <rudalics <at> gmx.at> said:
>> Interestingly, if I run the gtk build under xfwm4 without its dumpfile
>> present, I do sometimes see the frame issue you reported, which
>> suggests itʼs a timing issue somewhere.
martin> How do you run a build without the dump file present?
You rename the emacs binary to something other than emacs (although
renaming the emacs.pdmp file would also work).
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Tue, 02 Mar 2021 08:25:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> martin> How do you run a build without the dump file present?
>
> You rename the emacs binary to something other than emacs (although
> renaming the emacs.pdmp file would also work).
Neither of these work here. Maybe because I'm building out of tree.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Tue, 02 Mar 2021 08:25:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>> Interestingly, if I run the gtk build under xfwm4 without its dumpfile
>> present, I do sometimes see the frame issue you reported, which
>> suggests itʼs a timing issue somewhere.
>
> Evidence in favor of that suggestion may be the following observations:
> I can reliably reproduce the problematic display (on xfwm4-4.14.1 with
> GTK+ 3.24.17) with the first invocation below, but not with the second
> invocation:
Why is this evidence in favor of the above suggestion?
> $ emacs-master -Q --eval "(customize-set-variable 'default-frame-alist '((cursor-color . \"red3\") (width . 80) (height . 32)))"
>
> $ emacs-master -Q --eval "(progn (sleep-for .1) (customize-set-variable 'default-frame-alist '((cursor-color . \"red3\") (width . 80) (height . 32))))"
>
> Yet I can also reproduce the display problem with the following
> invocation:
>
> $ emacs-master -Q --eval "(progn (sit-for .1) (customize-set-variable 'default-frame-alist '((cursor-color . \"red3\") (width . 80) (height . 32))))"
Both `sleep-for' and `sit-for' with an abismal small argument work here,
0 does not. So the problem still seems that redisplay misses a pending
window change. I have no idea why `sleep-for' and `sit-for' behave
differently for you though.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Tue, 02 Mar 2021 09:08:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 46827 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> So the problem still seems that redisplay misses a pending
> window change.
Confirmed meanwhile. The attached patch fixes the problem here. Eli
will tell use whether we can put that do_pending_window_change in some
suitable safe place within redisplay_internal.
martin
[xdisp.c.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Tue, 02 Mar 2021 09:18:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 46827 <at> debbugs.gnu.org (full text, mbox):
(I saw your post with the do_pending_window_change patch just as I was
about to send the following, which therefore may now be irrelevant. I
haven't tried the patch yet.)
On Tue, 2 Mar 2021 09:24:38 +0100 martin rudalics <rudalics <at> gmx.at> wrote:
>>> Interestingly, if I run the gtk build under xfwm4 without its dumpfile
>>> present, I do sometimes see the frame issue you reported, which
>>> suggests itʼs a timing issue somewhere.
>>
>> Evidence in favor of that suggestion may be the following observations:
>> I can reliably reproduce the problematic display (on xfwm4-4.14.1 with
>> GTK+ 3.24.17) with the first invocation below, but not with the second
>> invocation:
>
> Why is this evidence in favor of the above suggestion?
Since sleep-for pauses without redisplay and sit-for pauses after
redisplay, I thought that points to a possible timing issue.
>> $ emacs-master -Q --eval "(customize-set-variable 'default-frame-alist
>> '((cursor-color . \"red3\") (width . 80) (height . 32)))"
>>
>> $ emacs-master -Q --eval "(progn (sleep-for .1) (customize-set-variable
>> 'default-frame-alist '((cursor-color . \"red3\") (width . 80) (height
>> . 32))))"
>>
>> Yet I can also reproduce the display problem with the following
>> invocation:
>>
>> $ emacs-master -Q --eval "(progn (sit-for .1) (customize-set-variable
>> 'default-frame-alist '((cursor-color . \"red3\") (width . 80) (height
>> . 32))))"
>
> Both `sleep-for' and `sit-for' with an abismal small argument work here,
> 0 does not. So the problem still seems that redisplay misses a pending
> window change. I have no idea why `sleep-for' and `sit-for' behave
> differently for you though.
I also see the problem consistently with (sit-for .01) and (sit-for
.001) but consistently don't see it with (sit-for .00001) and (sit-for
.000001). With (sit-for .0001) the problems has appeared on some
invocations and not on others. With sleep-for I haven't seen the
problem with .1, .01, .001 or .0001, but with .00001 and .000001 I have
seen it on some invocations but not on others. With both (sit-for 0)
and (sleep-for 0) I've seen the problem on some invocations and not seen
it on others. These observations also suggest to me a timing issue, but
my understanding of such things is very likely too poor to justify and
inferences.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Tue, 02 Mar 2021 10:03:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>>>> Interestingly, if I run the gtk build under xfwm4 without its dumpfile
>>>> present, I do sometimes see the frame issue you reported, which
>>>> suggests itʼs a timing issue somewhere.
>>>
>>> Evidence in favor of that suggestion may be the following observations:
>>> I can reliably reproduce the problematic display (on xfwm4-4.14.1 with
>>> GTK+ 3.24.17) with the first invocation below, but not with the second
>>> invocation:
>>
>> Why is this evidence in favor of the above suggestion?
>
> Since sleep-for pauses without redisplay and sit-for pauses after
> redisplay, I thought that points to a possible timing issue.
I meant the "no dump file present issue". How is that related to timing
issues?
>> Both `sleep-for' and `sit-for' with an abismal small argument work here,
>> 0 does not. So the problem still seems that redisplay misses a pending
>> window change. I have no idea why `sleep-for' and `sit-for' behave
>> differently for you though.
I forgot to mention that both, `sleep-for' and `sit-for' with arbitrary
non-zero arguments give a good frame here. Only with a zero argument,
they give a bad frame.
> I also see the problem consistently with (sit-for .01) and (sit-for
> .001) but consistently don't see it with (sit-for .00001) and (sit-for
> .000001). With (sit-for .0001) the problems has appeared on some
> invocations and not on others. With sleep-for I haven't seen the
> problem with .1, .01, .001 or .0001, but with .00001 and .000001 I have
> seen it on some invocations but not on others. With both (sit-for 0)
> and (sleep-for 0) I've seen the problem on some invocations and not seen
> it on others. These observations also suggest to me a timing issue, but
> my understanding of such things is very likely too poor to justify and
> inferences.
These observations quite substantially contradict mine. Why would the
bad frame appear with `sit-for' and _larger_ timeouts? I'd have
expected the contrary. OTOH the `sleep-for' behavior sounds reasonable.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Tue, 02 Mar 2021 10:12:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 2 Mar 2021 10:07:02 +0100, martin rudalics <rudalics <at> gmx.at> said:
>> So the problem still seems that redisplay misses a pending
>> window change.
martin> Confirmed meanwhile. The attached patch fixes the problem here. Eli
martin> will tell use whether we can put that do_pending_window_change in some
martin> suitable safe place within redisplay_internal.
It fixes it for me as well in emacs-27 and master (and the
frame-height is correct), and doesnʼt appear to have broken anything
under Gnome.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Tue, 02 Mar 2021 14:12:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Tue, 2 Mar 2021 10:07:02 +0100
> Cc: 46827 <at> debbugs.gnu.org
>
> > So the problem still seems that redisplay misses a pending
> > window change.
>
> Confirmed meanwhile. The attached patch fixes the problem here. Eli
> will tell use whether we can put that do_pending_window_change in some
> suitable safe place within redisplay_internal.
What's wrong with this place? But please note that after calling
do_pending_window_change you need to perform the "maybe the selected
window changed" dance we do after other similar calls.
Otherwise, I'm okay with this change, but only on master. Emacs 27.2
will have to make do with what we have now.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Tue, 02 Mar 2021 16:08:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 46827 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> What's wrong with this place?
Actually, it's not needed. I just have to call do_pending_window_change
_after_ updating the tool bar as in the attached patch.
> But please note that after calling
> do_pending_window_change you need to perform the "maybe the selected
> window changed" dance we do after other similar calls.
I suppose the
do_pending_window_change could change the selected_window due to
frame resizing which makes the selected window too small.
is some sort of cargo cult now. While frame resizing can make the
selected window small, it will neither remove nor change it.
But since the menu and tool bar code _can_ change the selected window
we'll still have to cater for it.
> Otherwise, I'm okay with this change, but only on master. Emacs 27.2
> will have to make do with what we have now.
Don't worry. Even on master we could condition it on GTK3. I'd just
want to find out why it works around the problem in the first place.
And I have a second, similar GTK3-only frame resizing problem with a
similar effect that, however, becomes virulent only after resizing a
frame manually with the mouse.
martin
[xdisp.c.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Tue, 02 Mar 2021 16:36:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> Cc: stephen.berman <at> gmx.net, rpluim <at> gmail.com, 46827 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Tue, 2 Mar 2021 17:07:16 +0100
>
> > What's wrong with this place?
>
> Actually, it's not needed. I just have to call do_pending_window_change
> _after_ updating the tool bar as in the attached patch.
Thanks, but is there any reason to remove the call before updating the
tool bar? You see, I believe one of the reasons for the need to
clear_garbaged_frames is that call you suggest to remove. Why not
leave it there, and _add_ one more call after prepare_menu_bars (and
perhaps condition it on the same condition as prepare_menu_bars)?
> > But please note that after calling
> > do_pending_window_change you need to perform the "maybe the selected
> > window changed" dance we do after other similar calls.
>
> I suppose the
>
> do_pending_window_change could change the selected_window due to
> frame resizing which makes the selected window too small.
>
> is some sort of cargo cult now. While frame resizing can make the
> selected window small, it will neither remove nor change it.
Never-ever?
> > Otherwise, I'm okay with this change, but only on master. Emacs 27.2
> > will have to make do with what we have now.
>
> Don't worry. Even on master we could condition it on GTK3. I'd just
> want to find out why it works around the problem in the first place.
I suspect that the code which calculates the dimensions of the tool
bar causes this.
> And I have a second, similar GTK3-only frame resizing problem with a
> similar effect that, however, becomes virulent only after resizing a
> frame manually with the mouse.
Fun.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Wed, 03 Mar 2021 08:49:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 46827 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Thanks, but is there any reason to remove the call before updating the
> tool bar? You see, I believe one of the reasons for the need to
> clear_garbaged_frames is that call you suggest to remove. Why not
> leave it there, and _add_ one more call after prepare_menu_bars (and
> perhaps condition it on the same condition as prepare_menu_bars)?
We can obviously do that (see attached patch). But is there any reason
we cannot run the
do_pending_window_change (true);
clear_garbaged_frames ();
_after_ the
prepare_menu_bars ();
do_pending_window_change (true);
block?
In either case, the more I look into this, the more things confuse me.
For example, why does
if (!must_finish)
{
do_pending_window_change (true);
/* If selected_window changed, redisplay again. */
if (WINDOWP (selected_window)
&& (w = XWINDOW (selected_window)) != sw)
goto retry;
not check for windows_or_buffers_changed too just as we do after the
third do_pending_window_change call? But then I don't understand why we
check for windows_or_buffers_changed at all. adjust_frame_size doesn't
set that IIUC but it does garbage the frame - why don't we check that in
redisplay_internal?
>> While frame resizing can make the
>> selected window small, it will neither remove nor change it.
>
> Never-ever?
Never-ever. Fdelete_window_internal, Fdelete_other_windows_internal and
Fset_window_configuration are the only functions allowed to delete
windows. run_window_change_functions could delete the selected window
so we probably should do the w == sw check after that now.
martin
[xdisp.c.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Wed, 03 Mar 2021 09:07:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: stephen.berman <at> gmx.net, rpluim <at> gmail.com, 46827 <at> debbugs.gnu.org
> Date: Wed, 3 Mar 2021 09:48:16 +0100
>
> > Thanks, but is there any reason to remove the call before updating the
> > tool bar? You see, I believe one of the reasons for the need to
> > clear_garbaged_frames is that call you suggest to remove. Why not
> > leave it there, and _add_ one more call after prepare_menu_bars (and
> > perhaps condition it on the same condition as prepare_menu_bars)?
>
> We can obviously do that (see attached patch). But is there any reason
> we cannot run the
>
> do_pending_window_change (true);
> clear_garbaged_frames ();
>
> _after_ the
>
> prepare_menu_bars ();
> do_pending_window_change (true);
>
> block?
I have no idea, and don't know how to check that. We could try, and
then be ready to fix any adverse effects this could cause.
> In either case, the more I look into this, the more things confuse me.
> For example, why does
>
> if (!must_finish)
> {
> do_pending_window_change (true);
> /* If selected_window changed, redisplay again. */
> if (WINDOWP (selected_window)
> && (w = XWINDOW (selected_window)) != sw)
> goto retry;
>
> not check for windows_or_buffers_changed too just as we do after the
> third do_pending_window_change call?
Because going to 'retry' will eventually make that check again. Or
maybe I don't understand what exactly are you asking here?
> But then I don't understand why we
> check for windows_or_buffers_changed at all. adjust_frame_size doesn't
> set that IIUC but it does garbage the frame - why don't we check that in
> redisplay_internal?
Sorry, I don't understand the question. We _are_ talking about
redisplay_internal, right? and redisplay_internal does check
windows_or_buffers_changed, right? so what do you mean by "why don't
we check that in redisplay_internal"? and what is "that" in this case?
> >> While frame resizing can make the
> >> selected window small, it will neither remove nor change it.
> >
> > Never-ever?
>
> Never-ever. Fdelete_window_internal, Fdelete_other_windows_internal and
> Fset_window_configuration are the only functions allowed to delete
> windows.
Not even due to some Lisp hook run directly or indirectly when the
frame is resized?
If this can never happen, we should replace the test with an
assertion, and wait for it to fire if we are missing something.
> run_window_change_functions could delete the selected window
> so we probably should do the w == sw check after that now.
Yes, I think so. Patches welcome.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Wed, 03 Mar 2021 09:41:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>> In either case, the more I look into this, the more things confuse me.
>> For example, why does
>>
>> if (!must_finish)
>> {
>> do_pending_window_change (true);
>> /* If selected_window changed, redisplay again. */
>> if (WINDOWP (selected_window)
>> && (w = XWINDOW (selected_window)) != sw)
>> goto retry;
>>
>> not check for windows_or_buffers_changed too just as we do after the
>> third do_pending_window_change call?
>
> Because going to 'retry' will eventually make that check again. Or
> maybe I don't understand what exactly are you asking here?
The check above doesn't care about windows_or_buffers_changed. The last
one in redisplay_internal does:
/* Change frame size now if a change is pending. */
do_pending_window_change (true);
/* If we just did a pending size change, or have additional
visible frames, or selected_window changed, redisplay again. */
if ((windows_or_buffers_changed && !pending)
|| (WINDOWP (selected_window)
&& (w = XWINDOW (selected_window)) != sw))
goto retry;
So if in the (!must_finish) guarded check windows_or_buffers_changed was
set but the selected window remained unchanged, we don't go to retry.
>> But then I don't understand why we
>> check for windows_or_buffers_changed at all. adjust_frame_size doesn't
>> set that IIUC but it does garbage the frame - why don't we check that in
>> redisplay_internal?
>
> Sorry, I don't understand the question. We _are_ talking about
> redisplay_internal, right? and redisplay_internal does check
> windows_or_buffers_changed, right? so what do you mean by "why don't
> we check that in redisplay_internal"? and what is "that" in this case?
I meant to ask why we don't check the f->garbaged flag of the frame
instead of windows_or_buffers_changed. do_pending_window_change to my
knowledge does not set windows_or_buffers_changed but sets the garbaged
flag.
>> Never-ever. Fdelete_window_internal, Fdelete_other_windows_internal and
>> Fset_window_configuration are the only functions allowed to delete
>> windows.
>
> Not even due to some Lisp hook run directly or indirectly when the
> frame is resized?
run_window_scroll_functions could do it later on, but that is run by
redisplay itself.
> If this can never happen, we should replace the test with an
> assertion, and wait for it to fire if we are missing something.
I'll try that here.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Sat, 06 Mar 2021 11:16:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> Cc: stephen.berman <at> gmx.net, rpluim <at> gmail.com, 46827 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Wed, 3 Mar 2021 10:40:04 +0100
>
> >> if (!must_finish)
> >> {
> >> do_pending_window_change (true);
> >> /* If selected_window changed, redisplay again. */
> >> if (WINDOWP (selected_window)
> >> && (w = XWINDOW (selected_window)) != sw)
> >> goto retry;
> >>
> >> not check for windows_or_buffers_changed too just as we do after the
> >> third do_pending_window_change call?
> >
> > Because going to 'retry' will eventually make that check again. Or
> > maybe I don't understand what exactly are you asking here?
>
> The check above doesn't care about windows_or_buffers_changed. The last
> one in redisplay_internal does:
>
> /* Change frame size now if a change is pending. */
> do_pending_window_change (true);
>
> /* If we just did a pending size change, or have additional
> visible frames, or selected_window changed, redisplay again. */
> if ((windows_or_buffers_changed && !pending)
> || (WINDOWP (selected_window)
> && (w = XWINDOW (selected_window)) != sw))
> goto retry;
>
> So if in the (!must_finish) guarded check windows_or_buffers_changed was
> set but the selected window remained unchanged, we don't go to retry.
I still don't see the problem, because that last check you show above
will catch that, right?
> >> But then I don't understand why we
> >> check for windows_or_buffers_changed at all. adjust_frame_size doesn't
> >> set that IIUC but it does garbage the frame - why don't we check that in
> >> redisplay_internal?
> >
> > Sorry, I don't understand the question. We _are_ talking about
> > redisplay_internal, right? and redisplay_internal does check
> > windows_or_buffers_changed, right? so what do you mean by "why don't
> > we check that in redisplay_internal"? and what is "that" in this case?
>
> I meant to ask why we don't check the f->garbaged flag of the frame
> instead of windows_or_buffers_changed. do_pending_window_change to my
> knowledge does not set windows_or_buffers_changed but sets the garbaged
> flag.
SET_FRAME_GARBAGED also causes windows_or_buffers_changed to be set.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Sat, 06 Mar 2021 19:29:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> I still don't see the problem, because that last check you show above
> will catch that, right?
You mean that if windows_or_buffers_changed, we handle that in the last
check and all the former check has to do is to assure that the selected
window is right? Then why do we call do_pending_window_change at all in
the "second" case. Because we might go to end_of_redisplay right from
there? But then the third check won't catch it. I'm clearly confused.
> SET_FRAME_GARBAGED also causes windows_or_buffers_changed to be set.
Via 'redisplay_other_windows', I see.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Tue, 27 Apr 2021 08:24:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 46827 <at> debbugs.gnu.org (full text, mbox):
tags 46827 fixed
close 46827 28.1
quit
> With a GTK3 build I start Emacs with the following initial file
> contents:
>
> (customize-set-variable
> 'default-frame-alist
> '((cursor-color . "red3")
> (width . 80)
> (height . 32)))
>
> Here this results in a frame that is 36 lines high, has a root window of
> 31 lines and a minibuffer window of 1 line. The remaining four lines at
> the bottom of the frame are (more or less) empty.
As Robert and Stephen have independently observed, this is a Heisenbug.
It's due to to the fact that WM notifications about new frame sizes may
be processed earlier or later. I tried to fix that behavior in commit
a190b4cfd8b6f42a91678ac7292e1cceccd168e7 by having adjust_frame_size
pick up such notifications on the fly and am closing this bug.
Thanks, martin
Added tag(s) fixed.
Request was from
martin rudalics <rudalics <at> gmx.at>
to
control <at> debbugs.gnu.org.
(Tue, 27 Apr 2021 08:24:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 28.1, send any further explanations to
46827 <at> debbugs.gnu.org and martin rudalics <rudalics <at> gmx.at>
Request was from
martin rudalics <rudalics <at> gmx.at>
to
control <at> debbugs.gnu.org.
(Tue, 27 Apr 2021 08:24:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Thu, 29 Apr 2021 16:32:02 GMT)
Full text and
rfc822 format available.
Message #111 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> It's due to to the fact that WM notifications about new frame sizes may
> be processed earlier or later. I tried to fix that behavior in commit
> a190b4cfd8b6f42a91678ac7292e1cceccd168e7 by having adjust_frame_size
> pick up such notifications on the fly and am closing this bug.
Unfortunately, this commit caused a regression: now there is distracting
blinking of the frame that looks like the visual effect of visible-bell
when it flashes the frame to represent a bell.
This problem can be reproduced only in Gnus. With such configuration:
(push '("\\`\\*Summary .*\\*\\'" .
(display-buffer-in-tab
(tab-name . "*Summary*")))
display-buffer-alist)
opening a Gnus group in a new tab flashes the whole frame where empty space
instead of the frame content is visible for a short time.
This problem can't be reproduced with just creating a new tab,
it only manifests in Gnus, maybe something in gnus-summary-read-group-1
with gnus-configure-windows forces frame redisplay or something like this.
This problem doesn't exist without recent changes in a190b4cfd8.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Thu, 29 Apr 2021 17:07:02 GMT)
Full text and
rfc822 format available.
Message #114 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>> It's due to to the fact that WM notifications about new frame sizes may
>> be processed earlier or later. I tried to fix that behavior in commit
>> a190b4cfd8b6f42a91678ac7292e1cceccd168e7 by having adjust_frame_size
>> pick up such notifications on the fly and am closing this bug.
>
> Unfortunately, this commit caused a regression: now there is distracting
> blinking of the frame that looks like the visual effect of visible-bell
> when it flashes the frame to represent a bell.
>
> This problem can be reproduced only in Gnus. With such configuration:
>
> (push '("\\`\\*Summary .*\\*\\'" .
> (display-buffer-in-tab
> (tab-name . "*Summary*")))
> display-buffer-alist)
>
> opening a Gnus group in a new tab flashes the whole frame where empty space
> instead of the frame content is visible for a short time.
>
> This problem can't be reproduced with just creating a new tab,
> it only manifests in Gnus, maybe something in gnus-summary-read-group-1
> with gnus-configure-windows forces frame redisplay or something like this.
>
> This problem doesn't exist without recent changes in a190b4cfd8.
Please try to provide some sort of recipe to reproduce this. Ideally
without Gnus because I never used it. Also, I've never seen a frame
"flash". Is that a new frame? Is there anything broken in the frame
after the flash?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Thu, 29 Apr 2021 23:21:02 GMT)
Full text and
rfc822 format available.
Message #117 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>> opening a Gnus group in a new tab flashes the whole frame where empty space
>> instead of the frame content is visible for a short time.
>>
>> This problem can't be reproduced with just creating a new tab,
>> it only manifests in Gnus, maybe something in gnus-summary-read-group-1
>> with gnus-configure-windows forces frame redisplay or something like this.
>>
>> This problem doesn't exist without recent changes in a190b4cfd8.
>
> Please try to provide some sort of recipe to reproduce this. Ideally
> without Gnus because I never used it. Also, I've never seen a frame
Sorry, not easy to distill many different things Gnus does to massage windows
into a simpler test case.
> "flash". Is that a new frame? Is there anything broken in the frame
> after the flash?
It's in the same frame, and nothing is broken after the flash.
The visual effect is that after creating a new tab, everything
is erased on the frame including tab bars and the mode line
for a short time, and then redrawn back.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Fri, 30 Apr 2021 06:27:02 GMT)
Full text and
rfc822 format available.
Message #120 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>> Please try to provide some sort of recipe to reproduce this. Ideally
>> without Gnus because I never used it. Also, I've never seen a frame
>
> Sorry, not easy to distill many different things Gnus does to massage windows
> into a simpler test case.
I understand. But since nobody else has reported a similar issue till
now, I strongly suspect that `display-buffer-in-tab' is triggering it.
>> "flash". Is that a new frame? Is there anything broken in the frame
>> after the flash?
>
> It's in the same frame, and nothing is broken after the flash.
> The visual effect is that after creating a new tab, everything
> is erased on the frame including tab bars and the mode line
> for a short time, and then redrawn back.
If this is GTK can you try with `x-wait-for-event-timeout' set to say 10
and tell whether that "flash" then takes ten seconds? Here I've never
seen that "everything is erased on the frame" - usually some garbage
from elsewhere remains ...
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Fri, 30 Apr 2021 17:15:02 GMT)
Full text and
rfc822 format available.
Message #123 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> If this is GTK can you try with `x-wait-for-event-timeout' set to say 10
> and tell whether that "flash" then takes ten seconds? Here I've never
> seen that "everything is erased on the frame" - usually some garbage
> from elsewhere remains ...
Changing x-wait-for-event-timeout from 0.1 to 10 has no effect
on x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0.
I tried to add a message at the top of window--display-buffer,
and there are no more flashes when a message is displayed.
Then tried to add `(sit-for 0)' to window--display-buffer,
and no flashes anymore too. So it seems this is a Heisenbug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Fri, 30 Apr 2021 17:38:02 GMT)
Full text and
rfc822 format available.
Message #126 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>> If this is GTK can you try with `x-wait-for-event-timeout' set to say 10
>> and tell whether that "flash" then takes ten seconds? Here I've never
>> seen that "everything is erased on the frame" - usually some garbage
>> from elsewhere remains ...
>
> Changing x-wait-for-event-timeout from 0.1 to 10 has no effect
> on x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0.
>
> I tried to add a message at the top of window--display-buffer,
> and there are no more flashes when a message is displayed.
>
> Then tried to add `(sit-for 0)' to window--display-buffer,
> and no flashes anymore too. So it seems this is a Heisenbug.
Is the behavior in any way frame related - do you resize your frame, add
a tab bar, resize the tab bar? I did not touch the Emacs window code.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Sat, 01 May 2021 20:34:01 GMT)
Full text and
rfc822 format available.
Message #129 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>> I tried to add a message at the top of window--display-buffer,
>> and there are no more flashes when a message is displayed.
>>
>> Then tried to add `(sit-for 0)' to window--display-buffer,
>> and no flashes anymore too. So it seems this is a Heisenbug.
>
> Is the behavior in any way frame related - do you resize your frame, add
> a tab bar, resize the tab bar? I did not touch the Emacs window code.
No frame resizes, the frame always stays maximized and undecorated,
and the tab bar is not resized.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Sun, 02 May 2021 07:40:01 GMT)
Full text and
rfc822 format available.
Message #132 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> No frame resizes, the frame always stays maximized and undecorated,
> and the tab bar is not resized.
Let's check whether the frame code is affected. With you original
scenario and also with the two scenarios where you successfully suppress
the flashes do
1: Eval (setq frame-size-history '(100))
2: Run the Gnus setup
3: Eval (progn (frame--size-history) (pop-to-buffer "*frame-size-history*"))
all in one and the same frame. Then post the contents of the buffer
*frame-size-history* for each of them.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Sun, 02 May 2021 22:04:02 GMT)
Full text and
rfc822 format available.
Message #135 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> Let's check whether the frame code is affected. With you original
> scenario and also with the two scenarios where you successfully suppress
> the flashes do
Actually, now there is only one successful scenario: it doesn't flash
with sit-for, but still flashes with a message.
> 1: Eval (setq frame-size-history '(100))
>
> 2: Run the Gnus setup
>
> 3: Eval (progn (frame--size-history) (pop-to-buffer "*frame-size-history*"))
>
> all in one and the same frame. Then post the contents of the buffer
> *frame-size-history* for each of them.
1. when the frame flashes:
Frame size history of #<frame *Minibuf-1* 0x55555935ffb0>
tab-bar-lines (3), TS=640x610~>640x612, TC=80x35~>80x36, IS=656x610~>656x612, MS=32x51 IH IV
tab-bar-lines (3), TS=640x612~>640x610, TC=80x36~>80x35, IS=656x612~>656x610, MS=80x85 IH IV
x_make_frame_visible
set_window_configuration (4), MS=80x85 IH IV
2. when no flash after adding sit-for in window--display-buffer:
Frame size history of #<frame *Minibuf-1* 0x55555935ffb0>
tab-bar-lines (3), TS=640x610~>640x612, TC=80x35~>80x36, IS=656x610~>656x612, MS=32x51 IH IV
tab-bar-lines (3), TS=640x612~>640x610, TC=80x36~>80x35, IS=656x612~>656x610, MS=32x51 IH IV
x_make_frame_visible
set_window_configuration (4), MS=80x85 IH IV
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 03 May 2021 07:50:02 GMT)
Full text and
rfc822 format available.
Message #138 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> Actually, now there is only one successful scenario: it doesn't flash
> with sit-for, but still flashes with a message.
Does "now" mean after my most recent commit?
>> 1: Eval (setq frame-size-history '(100))
>>
>> 2: Run the Gnus setup
>>
>> 3: Eval (progn (frame--size-history) (pop-to-buffer "*frame-size-history*"))
>>
>> all in one and the same frame. Then post the contents of the buffer
>> *frame-size-history* for each of them.
>
> 1. when the frame flashes:
>
> Frame size history of #<frame *Minibuf-1* 0x55555935ffb0>
> tab-bar-lines (3), TS=640x610~>640x612, TC=80x35~>80x36, IS=656x610~>656x612, MS=32x51 IH IV
> tab-bar-lines (3), TS=640x612~>640x610, TC=80x36~>80x35, IS=656x612~>656x610, MS=80x85 IH IV
> x_make_frame_visible
> set_window_configuration (4), MS=80x85 IH IV
>
> 2. when no flash after adding sit-for in window--display-buffer:
>
> Frame size history of #<frame *Minibuf-1* 0x55555935ffb0>
> tab-bar-lines (3), TS=640x610~>640x612, TC=80x35~>80x36, IS=656x610~>656x612, MS=32x51 IH IV
> tab-bar-lines (3), TS=640x612~>640x610, TC=80x36~>80x35, IS=656x612~>656x610, MS=32x51 IH IV
> x_make_frame_visible
> set_window_configuration (4), MS=80x85 IH IV
Didn't you earlier say that all this happens in a maximized frame? The
sizes above seem to contradict that. In either case, someone requests
to enlarge and shrink the tab bar by two pixels which contradicts your
earlier "and the tab bar is not resized". So who wants to do that to
the tab bar and why? And who wants to set the window configuration here
and why?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 03 May 2021 16:53:01 GMT)
Full text and
rfc822 format available.
Message #141 received at 46827 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Please try it and tell me whether the frame size history (hoperemains empty
now.
> > 1. when the frame flashes:
> >
> > Frame size history of #<frame *Minibuf-1* 0x55555935ffb0>
> > tab-bar-lines (3), TS=640x610~>640x612, TC=80x35~>80x36, IS=656x610~>656x612, MS=32x51 IH IV
> > tab-bar-lines (3), TS=640x612~>640x610, TC=80x36~>80x35, IS=656x612~>656x610, MS=80x85 IH IV
> > x_make_frame_visible
> > set_window_configuration (4), MS=80x85 IH IV
> >
> > 2. when no flash after adding sit-for in window--display-buffer:
> >
> > Frame size history of #<frame *Minibuf-1* 0x55555935ffb0>
> > tab-bar-lines (3), TS=640x610~>640x612, TC=80x35~>80x36, IS=656x610~>656x612, MS=32x51 IH IV
> > tab-bar-lines (3), TS=640x612~>640x610, TC=80x36~>80x35, IS=656x612~>656x610, MS=32x51 IH IV
> > x_make_frame_visible
> > set_window_configuration (4), MS=80x85 IH IV
>
> Didn't you earlier say that all this happens in a maximized frame? The
> sizes above seem to contradict that. In either case, someone requests
> to enlarge and shrink the tab bar by two pixels which contradicts your
> earlier "and the tab bar is not resized". So who wants to do that to
> the tab bar and why? And who wants to set the window configuration here
> and why?
What apparently happens is the following: x_set_tab_bar_lines (why?)
gets called all the time with a VALUE of 1 and translates that to
FRAME_LINE_HEIGHT (f) when calling x_change_tab_bar_height. So the
latter sets FRAME_TAB_BAR_HEIGHT (f) to FRAME_LINE_HEIGHT (f) which is
two pixels less than the height needed to display the tab bar. This
means we enlarge and move upwards the root window by two pixels and
later shrink and move it down when redisplay has calculated the new
size.
The attached patch tries to fix that. Note that a simple
nlines != olines
is not sufficient since the tab bar occupies 2 lines while VALUE is 1.
Maybe we should do a similar thing for the tool and/or menu bars (but I
recall that some builds do process a VALUE > 1 specially for them).
martin
[xfns.c.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 03 May 2021 17:05:01 GMT)
Full text and
rfc822 format available.
Message #144 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>> Actually, now there is only one successful scenario: it doesn't flash
>> with sit-for, but still flashes with a message.
>
> Does "now" mean after my most recent commit?
I don't know whether it affected since anyway sit-for can be used for
workaround as a test without flash.
> Didn't you earlier say that all this happens in a maximized frame? The
> sizes above seem to contradict that.
For testing, I tried in an unmaximized frame, but the problem is the same.
> In either case, someone requests to enlarge and shrink the tab bar by
> two pixels which contradicts your earlier "and the tab bar is not
> resized".
There are no visible resizes.
> So who wants to do that to the tab bar and why?
I don't know who wants to resize by two pixels.
> And who wants to set the window configuration here and why?
I added a breakpoint in set-window-configuration, and it's called from
tab-bar-select-tab in Gnus.
In total there are 4 tab switches with 4 calls of set-window-configuration.
But after removing gnus-remove-some-windows, when set-window-configuration
is not called at all, there are still the same flashes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 03 May 2021 17:05:02 GMT)
Full text and
rfc822 format available.
Message #147 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> Please try it and tell me whether the frame size history (hoperemains empty
> now.
Tried it, and no flashes anymore, thanks!
Here is the frame size history:
Frame size history of #<frame *Minibuf-1* 0x55555f0f7a58>
x_make_frame_visible
set_window_configuration (4), MS=80x85 IH IV
> What apparently happens is the following: x_set_tab_bar_lines (why?)
> gets called all the time with a VALUE of 1 and translates that to
> FRAME_LINE_HEIGHT (f) when calling x_change_tab_bar_height. So the
> latter sets FRAME_TAB_BAR_HEIGHT (f) to FRAME_LINE_HEIGHT (f) which is
> two pixels less than the height needed to display the tab bar. This
> means we enlarge and move upwards the root window by two pixels and
> later shrink and move it down when redisplay has calculated the new
> size.
>
> The attached patch tries to fix that. Note that a simple
>
> nlines != olines
>
> is not sufficient since the tab bar occupies 2 lines while VALUE is 1.
>
> Maybe we should do a similar thing for the tool and/or menu bars (but I
> recall that some builds do process a VALUE > 1 specially for them).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 03 May 2021 17:33:01 GMT)
Full text and
rfc822 format available.
Message #150 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> Tried it, and no flashes anymore, thanks!
Fine.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Tue, 04 May 2021 08:08:01 GMT)
Full text and
rfc822 format available.
Message #153 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> > Tried it, and no flashes anymore, thanks!
Pushed now. But I think that tab-bar.el should really refrain from
updating the tab-bar-lines parameter from one positive value to another
(I suppose `tab-bar--update-tab-bar-lines' does that).
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Tue, 04 May 2021 21:46:02 GMT)
Full text and
rfc822 format available.
Message #156 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>> > Tried it, and no flashes anymore, thanks!
>
> Pushed now. But I think that tab-bar.el should really refrain from
> updating the tab-bar-lines parameter from one positive value to another
> (I suppose `tab-bar--update-tab-bar-lines' does that).
It seems tab-bar.el already updates only between 0 and 1.
But even updating between 0 and 1 caused the problems.
We have bug#46557 created from https://debbugs.gnu.org/46299#119
I tried the test case from this bug report, and it doesn't fail anymore.
Do you think your patch fixed this old bug?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Wed, 05 May 2021 07:26:01 GMT)
Full text and
rfc822 format available.
Message #159 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> It seems tab-bar.el already updates only between 0 and 1.
That's not what I've seen.
> But even updating between 0 and 1 caused the problems.
> We have bug#46557 created from https://debbugs.gnu.org/46299#119
> I tried the test case from this bug report, and it doesn't fail anymore.
> Do you think your patch fixed this old bug?
You mean an init file with
(set-frame-parameter nil 'tab-bar-lines 0)
(set-frame-parameter nil 'tab-bar-lines 1)
(set-frame-parameter nil 'tab-bar-lines 0)
and doing C-x t 2? I have never seen any problems with that so I can't
tell. But it's my experience that whatever we do to our frames, it's
hard to break the external menu bar.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Wed, 05 May 2021 21:00:04 GMT)
Full text and
rfc822 format available.
Message #162 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>> It seems tab-bar.el already updates only between 0 and 1.
>
> That's not what I've seen.
There are no other values used in source code of tab-bar.el.
But maybe sometimes the value of tab-bar-lines
becomes more than 1?
>> But even updating between 0 and 1 caused the problems.
>> We have bug#46557 created from https://debbugs.gnu.org/46299#119
>> I tried the test case from this bug report, and it doesn't fail anymore.
>> Do you think your patch fixed this old bug?
>
> You mean an init file with
>
> (set-frame-parameter nil 'tab-bar-lines 0)
> (set-frame-parameter nil 'tab-bar-lines 1)
> (set-frame-parameter nil 'tab-bar-lines 0)
>
> and doing C-x t 2? I have never seen any problems with that so I can't
> tell. But it's my experience that whatever we do to our frames, it's
> hard to break the external menu bar.
The bug was reproducible only on GNU/Linux, not on MS-Windows.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Thu, 06 May 2021 07:46:02 GMT)
Full text and
rfc822 format available.
Message #165 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>>> It seems tab-bar.el already updates only between 0 and 1.
>>
>> That's not what I've seen.
>
> There are no other values used in source code of tab-bar.el.
> But maybe sometimes the value of tab-bar-lines
> becomes more than 1?
It's 2 after the tab bar has been produced for the first time by the
display code. And that is what's been causing trouble for you. The
value was oscillating between 1 and 2.
>> But it's my experience that whatever we do to our frames, it's
>> hard to break the external menu bar.
>
> The bug was reproducible only on GNU/Linux, not on MS-Windows.
I've never been able to produce a "broken menu bar" on any build.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Fri, 07 May 2021 17:16:02 GMT)
Full text and
rfc822 format available.
Message #168 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>>>> It seems tab-bar.el already updates only between 0 and 1.
>>>
>>> That's not what I've seen.
>>
>> There are no other values used in source code of tab-bar.el.
>> But maybe sometimes the value of tab-bar-lines
>> becomes more than 1?
>
> It's 2 after the tab bar has been produced for the first time by the
> display code. And that is what's been causing trouble for you. The
> value was oscillating between 1 and 2.
Very strange indeed, I can't find the constant 2 in the source code.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 10 May 2021 08:24:02 GMT)
Full text and
rfc822 format available.
Message #171 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>>> But maybe sometimes the value of tab-bar-lines
>>> becomes more than 1?
>>
>> It's 2 after the tab bar has been produced for the first time by the
>> display code. And that is what's been causing trouble for you. The
>> value was oscillating between 1 and 2.
>
> Very strange indeed, I can't find the constant 2 in the source code.
Because for X it's done in x_change_tab_bar_height as (I suppose you
wrote that):
x_change_tab_bar_height (struct frame *f, int height)
{
int unit = FRAME_LINE_HEIGHT (f);
int old_height = FRAME_TAB_BAR_HEIGHT (f);
int lines = (height + unit - 1) / unit;
Lisp_Object fullscreen = get_frame_param (f, Qfullscreen);
/* Make sure we redisplay all windows in this frame. */
fset_redisplay (f);
/* Recalculate tab bar and frame text sizes. */
FRAME_TAB_BAR_HEIGHT (f) = height;
FRAME_TAB_BAR_LINES (f) = lines;
store_frame_param (f, Qtab_bar_lines, make_fixnum (lines));
If you call this with a HEIGHT that is larger than FRAME_LINE_HEIGHT you
already get a `tab-bar-lines' parameter that is larger than 1. With a
very small FRAME_LINE_HEIGHT and/or a very tall tab bar you may get more
than 2 lines.
This is an idiosyncrasy of our "live in a graphic world but think in
terms of a TTY" philosophy. The parameter should be a boolean and have
been called something like 'tab_bar_p' but there's no chance to change
that any more.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Mon, 10 May 2021 21:29:02 GMT)
Full text and
rfc822 format available.
Message #174 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> x_change_tab_bar_height (struct frame *f, int height)
> {
> int unit = FRAME_LINE_HEIGHT (f);
> int old_height = FRAME_TAB_BAR_HEIGHT (f);
> int lines = (height + unit - 1) / unit;
> Lisp_Object fullscreen = get_frame_param (f, Qfullscreen);
>
> /* Make sure we redisplay all windows in this frame. */
> fset_redisplay (f);
>
> /* Recalculate tab bar and frame text sizes. */
> FRAME_TAB_BAR_HEIGHT (f) = height;
> FRAME_TAB_BAR_LINES (f) = lines;
> store_frame_param (f, Qtab_bar_lines, make_fixnum (lines));
>
> If you call this with a HEIGHT that is larger than FRAME_LINE_HEIGHT you
> already get a `tab-bar-lines' parameter that is larger than 1. With a
> very small FRAME_LINE_HEIGHT and/or a very tall tab bar you may get more
> than 2 lines.
Indeed, initially:
lines = (17 + 17 - 1) / 17 = 1
but later:
lines = (19 + 17 - 1) / 17 = 2
> This is an idiosyncrasy of our "live in a graphic world but think in
> terms of a TTY" philosophy. The parameter should be a boolean and have
> been called something like 'tab_bar_p' but there's no chance to change
> that any more.
But what if the tab bar is so long that it wraps and really occupies 2 lines
on a GUI?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Tue, 11 May 2021 08:45:02 GMT)
Full text and
rfc822 format available.
Message #177 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> But what if the tab bar is so long that it wraps and really occupies 2 lines
> on a GUI?
What are "2 lines on a GUI"? If you mean "logical lines", only the
display engine - the entity responsible for detecting whether a tab bar
line must be wrapped - can tell. We could easily set the value of the
'tab-bar-lines' parameter to that - it would make more sense than what
we have now. Currently, (frame-parameter nil 'tab-bar-lines) yields "3"
when I have one logical tab bar line that wraps when I make the frame
narrow enough.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Tue, 11 May 2021 18:32:02 GMT)
Full text and
rfc822 format available.
Message #180 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>> But what if the tab bar is so long that it wraps and really occupies 2 lines
>> on a GUI?
>
> What are "2 lines on a GUI"? If you mean "logical lines", only the
Yes, wrapped logical lines.
> display engine - the entity responsible for detecting whether a tab bar
> line must be wrapped - can tell. We could easily set the value of the
> 'tab-bar-lines' parameter to that - it would make more sense than what
> we have now. Currently, (frame-parameter nil 'tab-bar-lines) yields "3"
> when I have one logical tab bar line that wraps when I make the frame
> narrow enough.
I see the same.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Wed, 12 May 2021 08:48:02 GMT)
Full text and
rfc822 format available.
Message #183 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>> display engine - the entity responsible for detecting whether a tab bar
>> line must be wrapped - can tell. We could easily set the value of the
>> 'tab-bar-lines' parameter to that - it would make more sense than what
>> we have now. Currently, (frame-parameter nil 'tab-bar-lines) yields "3"
>> when I have one logical tab bar line that wraps when I make the frame
>> narrow enough.
>
> I see the same.
Do we want to change it? Then we'd probably have to change the
semantics of this for tool bar and menu bar lines too. Note: In
practice we care only about zero or not zero here.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Wed, 12 May 2021 17:30:02 GMT)
Full text and
rfc822 format available.
Message #186 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>>> display engine - the entity responsible for detecting whether a tab bar
>>> line must be wrapped - can tell. We could easily set the value of the
>>> 'tab-bar-lines' parameter to that - it would make more sense than what
>>> we have now. Currently, (frame-parameter nil 'tab-bar-lines) yields "3"
>>> when I have one logical tab bar line that wraps when I make the frame
>>> narrow enough.
>>
>> I see the same.
>
> Do we want to change it? Then we'd probably have to change the
> semantics of this for tool bar and menu bar lines too.
Isn't this a bug that the tool bar and menu bar incorrectly calculate lines?
> Note: In practice we care only about zero or not zero here.
It could also help to detect the situation when lines are wrapped.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Thu, 13 May 2021 07:55:02 GMT)
Full text and
rfc822 format available.
Message #189 received at 46827 <at> debbugs.gnu.org (full text, mbox):
> Isn't this a bug that the tool bar and menu bar incorrectly calculate lines?
The lines are calculated correctly by rounding up when we divide the
object's pixel height by the default character height of the frame. But
that calculated value is useless on a GUI.
>> Note: In practice we care only about zero or not zero here.
>
> It could also help to detect the situation when lines are wrapped.
For internal objects (like the Lucid or Windows tool bar or your tab
bars) only the display engine can reliable do that. For external
objects (like the Motif or Windows menu bars) detecting wrapping is
unreliable anyway.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Thu, 13 May 2021 16:32:01 GMT)
Full text and
rfc822 format available.
Message #192 received at 46827 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> Isn't this a bug that the tool bar and menu bar incorrectly calculate lines?
>
> The lines are calculated correctly by rounding up when we divide the
> object's pixel height by the default character height of the frame. But
> that calculated value is useless on a GUI.
Accoring to window-total-height, the currently used rounding
in x_change_tab_bar_height corresponds to 'ceiling':
return make_fixnum (EQ (round, Qceiling)
? ((w->pixel_height + unit - 1) /unit)
On a TTY where the frame line height is 1, this gives the correct result.
But not on a GUI where the frame line height is measured in pixels.
When the argument 'round' of window-total-height is 'floor',
it uses the formula without subtracting 1 that works on a GUI too:
: (w->pixel_height / unit));
This patch fixes this in x_change_tab_bar_height. Do you think the same
fix should be applied to x_change_tool_bar_height as well?
[x_change_tab_bar_height.patch (text/x-diff, inline)]
diff --git a/src/xfns.c b/src/xfns.c
index e46616e6d6..82d22cc5f8 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -1640,7 +1640,7 @@ x_change_tab_bar_height (struct frame *f, int height)
{
int unit = FRAME_LINE_HEIGHT (f);
int old_height = FRAME_TAB_BAR_HEIGHT (f);
- int lines = (height + unit - 1) / unit;
+ int lines = height / unit;
Lisp_Object fullscreen = get_frame_param (f, Qfullscreen);
/* Make sure we redisplay all windows in this frame. */
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Fri, 14 May 2021 07:09:02 GMT)
Full text and
rfc822 format available.
Message #195 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>> The lines are calculated correctly by rounding up when we divide the
>> object's pixel height by the default character height of the frame. But
>> that calculated value is useless on a GUI.
>
> Accoring to window-total-height, the currently used rounding
> in x_change_tab_bar_height corresponds to 'ceiling':
>
> return make_fixnum (EQ (round, Qceiling)
> ? ((w->pixel_height + unit - 1) /unit)
>
> On a TTY where the frame line height is 1, this gives the correct result.
> But not on a GUI where the frame line height is measured in pixels.
>
> When the argument 'round' of window-total-height is 'floor',
> it uses the formula without subtracting 1 that works on a GUI too:
>
> : (w->pixel_height / unit));
>
> This patch fixes this in x_change_tab_bar_height. Do you think the same
> fix should be applied to x_change_tool_bar_height as well?
What does your patch fix? With a sufficiently small default font this
will still return a value > 1. In either case, the height of the
frame's inner rectangle plus those of internal tab, tool and menu bar
should equal the height of the native rectangle in lines. Did you check
that?
In my experience, there's no way to make column/line based variables and
functions always DTRT on a GUI. Code should avoid them.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Fri, 14 May 2021 18:29:02 GMT)
Full text and
rfc822 format available.
Message #198 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>> Accoring to window-total-height, the currently used rounding
>> in x_change_tab_bar_height corresponds to 'ceiling':
>>
>> return make_fixnum (EQ (round, Qceiling)
>> ? ((w->pixel_height + unit - 1) /unit)
>>
>> On a TTY where the frame line height is 1, this gives the correct result.
>> But not on a GUI where the frame line height is measured in pixels.
>>
>> When the argument 'round' of window-total-height is 'floor',
>> it uses the formula without subtracting 1 that works on a GUI too:
>>
>> : (w->pixel_height / unit));
>>
>> This patch fixes this in x_change_tab_bar_height. Do you think the same
>> fix should be applied to x_change_tool_bar_height as well?
>
> What does your patch fix?
There are no more oscillations between 1 and 2 on a GUI.
> With a sufficiently small default font this will still return a value > 1.
I use very small font, and the value is always 1. Only when the tab bar
is wrapped, the value becomes 2.
> In either case, the height of the frame's inner rectangle plus those
> of internal tab, tool and menu bar should equal the height of the
> native rectangle in lines. Did you check that?
I don't know how to check this.
> In my experience, there's no way to make column/line based variables and
> functions always DTRT on a GUI. Code should avoid them.
Is it possible to avoid this when tab-bar-lines are calculated?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46827; Package
emacs.
(Sat, 15 May 2021 07:58:01 GMT)
Full text and
rfc822 format available.
Message #201 received at 46827 <at> debbugs.gnu.org (full text, mbox):
>> What does your patch fix?
>
> There are no more oscillations between 1 and 2 on a GUI.
>
>> With a sufficiently small default font this will still return a value > 1.
>
> I use very small font, and the value is always 1. Only when the tab bar
> is wrapped, the value becomes 2.
I merely referred to the tool bar whose height (especially on KDE) often
exceeds that of the default font by more than 2. For the tab bar, try
to scale the tab-bar face by a factor of 2.0 or increase the height of
the `variable-pitch' face.
>> In either case, the height of the frame's inner rectangle plus those
>> of internal tab, tool and menu bar should equal the height of the
>> native rectangle in lines. Did you check that?
>
> I don't know how to check this.
I doubt that we do it correctly now. There's a check that tries to make
window sizes in lines and columns sum up correctly but there's no such
check for the frame decorations IIRC.
>> In my experience, there's no way to make column/line based variables and
>> functions always DTRT on a GUI. Code should avoid them.
>
> Is it possible to avoid this when tab-bar-lines are calculated?
IIUC we have two ways to calculate tab-bar-lines in a logically correct
way: Have the display engine do it explicitly whenever it detects that a
tab-bar line is wrapped or implicitly by inspecting the glyph matrix
after the display engine is done with the tab bar. A similar approach
can be used for the tool bar on Lucid/Motif/Windows and both tool and
menu bar on builds without toolkit support.
martin
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 12 Jun 2021 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 331 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.