* bug#22000: 25.0.50; Running dired changes frame width, gtk_distribute_natural_allocation throws assertion
@ 2015-11-23 20:55 David Engster
2015-11-24 8:28 ` martin rudalics
2018-07-15 18:09 ` bug#22000: Patch addressing the menu-bar frame-resize interaction Vivek Dasmohapatra
0 siblings, 2 replies; 97+ messages in thread
From: David Engster @ 2015-11-23 20:55 UTC (permalink / raw)
To: 22000
I've compiled from the emacs-25 branch (f146ea73a9ca6) simply with
'./configure' (output see below), but I've also seen this problem with
Emacs 24.5.
I do the following:
- emacs -Q
- Enter in the scratch buffer
(custom-set-faces
'(default ((t (:height 100 :family "DejaVu Sans Mono")))))
(set-frame-width nil 60)
- Run 'M-x dired'
What I see:
- The frame width suddenly becomes wider (to 78 characters)
- In the console output, I see
(emacs:27459): Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed
- I also see this assertion when I resize the frame with the mouse to a
smaller width than those 78 characters.
- I do *not* have these problems with a bitmap font like "Terminus".
- I also do *not* have these problems with a Lucid build.
This is on a Debian 8 machine with GTK '3.14.5-1+deb8u1'.
Configure output:
Configured for 'x86_64-unknown-linux-gnu'.
Where should the build process find the source code? .
What compiler should emacs be built with? gcc -std=gnu99 -g3 -O2
Should Emacs use the GNU version of malloc? yes
(Using Doug Lea's new malloc from the GNU C Library.)
Should Emacs use a relocating allocator for buffers? no
Should Emacs use mmap(2) for buffer allocation? no
What window system should Emacs use? x11
What toolkit should Emacs use? GTK3
Where do we find X Windows header files? Standard dirs
Where do we find X Windows libraries? Standard dirs
Does Emacs use -lXaw3d? no
Does Emacs use -lXpm? yes
Does Emacs use -ljpeg? yes
Does Emacs use -ltiff? yes
Does Emacs use a gif library? yes -lgif
Does Emacs use a png library? yes -lpng12
Does Emacs use -lrsvg-2? yes
Does Emacs use cairo? no
Does Emacs use imagemagick? yes
Does Emacs support sound? yes
Does Emacs use -lgpm? yes
Does Emacs use -ldbus? yes
Does Emacs use -lgconf? no
Does Emacs use GSettings? yes
Does Emacs use a file notification library? yes -lglibc (inotify)
Does Emacs use access control lists? no
Does Emacs use -lselinux? no
Does Emacs use -lgnutls? yes
Does Emacs use -lxml2? yes
Does Emacs use -lfreetype? yes
Does Emacs use -lm17n-flt? yes
Does Emacs use -lotf? yes
Does Emacs use -lxft? yes
Does Emacs directly use zlib? yes
Does Emacs have dynamic modules support? no
Does Emacs use toolkit scroll bars? yes
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: 25.0.50; Running dired changes frame width, gtk_distribute_natural_allocation throws assertion
2015-11-23 20:55 bug#22000: 25.0.50; Running dired changes frame width, gtk_distribute_natural_allocation throws assertion David Engster
@ 2015-11-24 8:28 ` martin rudalics
2015-11-24 16:48 ` David Engster
2018-07-15 18:09 ` bug#22000: Patch addressing the menu-bar frame-resize interaction Vivek Dasmohapatra
1 sibling, 1 reply; 97+ messages in thread
From: martin rudalics @ 2015-11-24 8:28 UTC (permalink / raw)
To: David Engster, 22000
> - In the console output, I see
>
> (emacs:27459): Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed
>
> - I also see this assertion when I resize the frame with the mouse to a
> smaller width than those 78 characters.
Does it also happen with ‘frame-resize-pixelwise’ non-nil?
martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: 25.0.50; Running dired changes frame width, gtk_distribute_natural_allocation throws assertion
2015-11-24 8:28 ` martin rudalics
@ 2015-11-24 16:48 ` David Engster
2015-11-24 19:26 ` martin rudalics
0 siblings, 1 reply; 97+ messages in thread
From: David Engster @ 2015-11-24 16:48 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000
[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]
martin rudalics writes:
>> - In the console output, I see
>>
>> (emacs:27459): Gtk-CRITICAL **:
>> gtk_distribute_natural_allocation: assertion 'extra_space >= 0'
>> failed
>>
>> - I also see this assertion when I resize the frame with the mouse to a
>> smaller width than those 78 characters.
>
> Does it also happen with ‘frame-resize-pixelwise’ non-nil?
Yes. But at least I know now what really triggers this problem: GTK
throws this assertion when the menubar is not completely visible. This
is also why running Dired triggers this, because it adds a bunch of
additional menu entries. The frame is then resized so that the menu-bar
fits.
I also have to correct myself: The font doesn't seem to have anything to
do with it; it also happens with Bitmap fonts, it was just by chance
that this configuration had the menu-bar disabled.
I realized that the menu-bar is the reason by putting a breakpoint into
g_log through which the assertion is displayed, and you see that
gtk_menu_bar_size_allocate is actually triggering this. I attached the
full and normal backtrace to this file (xbacktrace is empty).
-David
[-- Attachment #2: backtrace.txt --]
[-- Type: text/plain, Size: 10886 bytes --]
#0 g_log (log_domain=log_domain@entry=0x7ffff6db7edf "Gtk", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL,
format=format@entry=0x7ffff5185e25 "%s: assertion '%s' failed") at /tmp/buildd/glib2.0-2.42.1/./glib/gmessages.c:1075
#1 0x00007ffff513bfa9 in g_return_if_fail_warning (log_domain=log_domain@entry=0x7ffff6db7edf "Gtk",
pretty_function=pretty_function@entry=0x7ffff6e121c0 <__FUNCTION__.35024> "gtk_distribute_natural_allocation",
expression=expression@entry=0x7ffff6e11e07 "extra_space >= 0") at /tmp/buildd/glib2.0-2.42.1/./glib/gmessages.c:1088
#2 0x00007ffff6cb685a in gtk_distribute_natural_allocation (extra_space=-9, n_requested_sizes=<optimized out>, sizes=<optimized out>)
at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtksizerequest.c:801
#3 0x00007ffff6c45828 in gtk_menu_bar_size_allocate (widget=<optimized out>, allocation=<optimized out>) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkmenubar.c:544
#4 0x00007ffff540d233 in g_cclosure_marshal_VOID__BOXEDv (closure=0x1672600, return_value=<optimized out>, instance=<optimized out>, args=<optimized out>,
marshal_data=<optimized out>, n_params=<optimized out>, param_types=0x1603f50) at /tmp/buildd/glib2.0-2.42.1/./gobject/gmarshal.c:1160
#5 0x00007ffff540a3c2 in _g_closure_invoke_va (closure=0x7ffff6db7edf, closure@entry=0x1672600, return_value=0x8, return_value@entry=0x0, instance=0x7ffff5185e25,
instance@entry=0x199a400, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args@entry=0x7fffffffb9e0, n_params=-153018873, param_types=0x1682470)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:831
#6 0x00007ffff5424087 in g_signal_emit_valist (instance=0x199a400, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffb9e0)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3218
#7 0x00007ffff54249df in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3365
#8 0x00007ffff6d67de7 in gtk_widget_size_allocate_with_baseline (widget=0x199a400, allocation=0x0, baseline=-1) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwidget.c:6075
#9 0x00007ffff6b3e21d in gtk_box_size_allocate_no_center (widget=0x7fffdc00a660, allocation=0x7fffffffc050) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkbox.c:800
#10 0x00007ffff540d233 in g_cclosure_marshal_VOID__BOXEDv (closure=0x1672600, return_value=<optimized out>, instance=<optimized out>, args=<optimized out>,
marshal_data=<optimized out>, n_params=<optimized out>, param_types=0x1603f50) at /tmp/buildd/glib2.0-2.42.1/./gobject/gmarshal.c:1160
#11 0x00007ffff540a3c2 in _g_closure_invoke_va (closure=0x7ffff6db7edf, closure@entry=0x1672600, return_value=0x8, return_value@entry=0x0, instance=0x7ffff5185e25,
instance@entry=0x7fffdc00a660, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args@entry=0x7fffffffbf10, n_params=-153018873, param_types=0x1682470)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:831
#12 0x00007ffff5424087 in g_signal_emit_valist (instance=0x7fffdc00a660, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffbf10)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3218
#13 0x00007ffff54249df in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3365
#14 0x00007ffff6d67de7 in gtk_widget_size_allocate_with_baseline (widget=0x7fffdc00a660, allocation=0x0, baseline=-1)
at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwidget.c:6075
#15 0x00007ffff6d681aa in gtk_widget_size_allocate (widget=widget@entry=0x7fffdc00a660, allocation=allocation@entry=0x7fffffffc0d0)
at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwidget.c:6151
#16 0x00007ffff6d7e4d3 in gtk_window_size_allocate (widget=<optimized out>, allocation=<optimized out>) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwindow.c:7309
#17 0x00007ffff540a245 in g_closure_invoke (closure=0x1672600, return_value=0x0, n_param_values=2, param_values=0x7fffffffc2d0, invocation_hint=0x7fffffffc270)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:768
#18 0x00007ffff541b83b in signal_emit_unlocked_R (node=node@entry=0x1603ee0, detail=detail@entry=0, instance=instance@entry=0x1996240,
emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffc2d0) at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3483
#19 0x00007ffff5424778 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffc460)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3309
#20 0x00007ffff54249df in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3365
#21 0x00007ffff6d67de7 in gtk_widget_size_allocate_with_baseline (widget=0x1996240, allocation=0x0, baseline=-1) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwidget.c:6075
#22 0x00007ffff6d681aa in gtk_widget_size_allocate (widget=widget@entry=0x1996240, allocation=allocation@entry=0x7fffffffc690)
at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwidget.c:6151
#23 0x00007ffff6d78811 in gtk_window_move_resize (window=0x1996240) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwindow.c:9147
#24 gtk_window_check_resize (container=0x1996240) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwindow.c:7916
#25 0x00007ffff540a474 in _g_closure_invoke_va (closure=0x7ffff6db7edf, closure@entry=0x167b5c0, return_value=0x8, return_value@entry=0x0, instance=0x7ffff5185e25,
instance@entry=0x1996240, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args@entry=0x7fffffffc900, n_params=-153018873, param_types=0x1682470)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:831
---Type <return> to continue, or q <return> to quit---
#26 0x00007ffff5424087 in g_signal_emit_valist (instance=0x1996240, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffc900)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3218
#27 0x00007ffff54249df in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3365
#28 0x00007ffff6b821fc in gtk_container_idle_sizer (clock=0x170b250, container=0x1996240) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkcontainer.c:1755
#29 0x00007ffff540a474 in _g_closure_invoke_va (closure=0x7ffff6db7edf, closure@entry=0x1e53780, return_value=0x8, return_value@entry=0x0, instance=0x7ffff5185e25,
instance@entry=0x170b250, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args@entry=0x7fffffffcc48, n_params=-153018873, param_types=0x1682470)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:831
#30 0x00007ffff5424087 in g_signal_emit_valist (instance=0x170b250, signal_id=<optimized out>, detail=0, var_args=0x7fffffffcc48)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3218
#31 0x00007ffff5424f2a in g_signal_emit_by_name (instance=0x7ffff6db7edf, instance@entry=0x170b250, detailed_signal=0x8 <error: Cannot access memory at address 0x8>,
detailed_signal@entry=0x7ffff681b736 "layout") at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3405
#32 0x00007ffff67b5974 in gdk_frame_clock_paint_idle (data=0x170b250) at /tmp/buildd/gtk+3.0-3.14.5/./gdk/gdkframeclockidle.c:408
#33 0x00007ffff67a7e78 in gdk_threads_dispatch (data=0x1860b40, data@entry=<error reading variable: value has been optimized out>)
at /tmp/buildd/gtk+3.0-3.14.5/./gdk/gdk.c:654
#34 0x00007ffff5135613 in g_timeout_dispatch (source=0x1e58820, callback=<optimized out>, user_data=<optimized out>) at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:4520
#35 0x00007ffff5134b6d in g_main_dispatch (context=0x16eacf0) at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3111
#36 g_main_context_dispatch (context=context@entry=0x16eacf0) at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3710
#37 0x00007ffff5134f48 in g_main_context_iterate (context=context@entry=0x16eacf0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3781
#38 0x00007ffff5134ffc in g_main_context_iteration (context=0x16eacf0, context@entry=0x0, may_block=may_block@entry=1) at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3842
#39 0x00007ffff6c2dcc5 in gtk_main_iteration () at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkmain.c:1308
#40 0x0000000000545c63 in XTread_socket (terminal=0x12fdb80, hold_quit=0x7fffffffcf60) at xterm.c:8775
#41 0x0000000000592262 in gobble_input () at keyboard.c:6771
#42 0x00000000005927e7 in handle_async_input () at keyboard.c:7023
#43 0x0000000000592806 in process_pending_signals () at keyboard.c:7037
#44 0x0000000000604c49 in Fmake_list (length=0, init=0) at alloc.c:2705
#45 0x00000000006361fb in concat (nargs=1, args=0x7fffffffd1a8, target_type=Lisp_Cons, last_special=false) at fns.c:633
#46 0x0000000000635b9a in Fcopy_sequence (arg=22459043) at fns.c:501
#47 0x000000000058c928 in timer_check () at keyboard.c:4447
#48 0x000000000058a0f6 in readable_events (flags=1) at keyboard.c:3304
#49 0x00000000005920ac in get_input_pending (flags=1) at keyboard.c:6686
#50 0x0000000000599894 in detect_input_pending_run_timers (do_display=true) at keyboard.c:9817
#51 0x000000000068a0db in wait_reading_process_output (time_limit=0, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=0, wait_proc=0x0, just_wait_proc=0)
at process.c:4963
#52 0x000000000058b16c in kbd_buffer_get_event (kbp=0x7fffffffd818, used_mouse_menu=0x7fffffffddff, end_time=0x0) at keyboard.c:3795
#53 0x0000000000586701 in read_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffffdbc0, used_mouse_menu=0x7fffffffddff) at keyboard.c:2121
#54 0x00000000005869d0 in read_decoded_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffffdbc0, prev_event=0, used_mouse_menu=0x7fffffffddff)
at keyboard.c:2184
#55 0x000000000058863c in read_char (commandflag=1, map=30806627, prev_event=0, used_mouse_menu=0x7fffffffddff, end_time=0x0) at keyboard.c:2779
#56 0x0000000000597c93 in read_key_sequence (keybuf=0x7fffffffdfb0, bufsize=30, prompt=0, dont_downcase_last=false, can_return_switch_frame=true,
fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9018
#57 0x00000000005846af in command_loop_1 () at keyboard.c:1343
#58 0x000000000062d0e3 in internal_condition_case (bfun=0x58426d <command_loop_1>, handlers=18912, hfun=0x5838db <cmd_error>) at eval.c:1309
#59 0x0000000000583e9b in command_loop_2 (ignore=0) at keyboard.c:1086
#60 0x000000000062c68d in internal_catch (tag=45696, func=0x583e72 <command_loop_2>, arg=0) at eval.c:1074
#61 0x0000000000583e3b in command_loop () at keyboard.c:1065
#62 0x00000000005833ba in recursive_edit_1 () at keyboard.c:671
#63 0x00000000005835c5 in Frecursive_edit () at keyboard.c:742
---Type <return> to continue, or q <return> to quit---
#64 0x00000000005813d8 in main (argc=2, argv=0x7fffffffe438) at emacs.c:1656
[-- Attachment #3: backtrace_full.txt --]
[-- Type: text/plain, Size: 36129 bytes --]
bt full
#0 g_log (log_domain=log_domain@entry=0x7ffff6db7edf "Gtk", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL,
format=format@entry=0x7ffff5185e25 "%s: assertion '%s' failed") at /tmp/buildd/glib2.0-2.42.1/./glib/gmessages.c:1075
args = {{
gp_offset = 0,
fp_offset = 0,
overflow_arg_area = 0x1631580,
reg_save_area = 0x7fffffffb600
}}
#1 0x00007ffff513bfa9 in g_return_if_fail_warning (log_domain=log_domain@entry=0x7ffff6db7edf "Gtk",
pretty_function=pretty_function@entry=0x7ffff6e121c0 <__FUNCTION__.35024> "gtk_distribute_natural_allocation",
expression=expression@entry=0x7ffff6e11e07 "extra_space >= 0") at /tmp/buildd/glib2.0-2.42.1/./glib/gmessages.c:1088
No locals.
#2 0x00007ffff6cb685a in gtk_distribute_natural_allocation (extra_space=-9, n_requested_sizes=<optimized out>, sizes=<optimized out>)
at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtksizerequest.c:801
spreading = <optimized out>
i = <optimized out>
__FUNCTION__ = "gtk_distribute_natural_allocation"
#3 0x00007ffff6c45828 in gtk_menu_bar_size_allocate (widget=<optimized out>, allocation=<optimized out>) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkmenubar.c:544
size = <optimized out>
ltr = 1
context = <optimized out>
flags = <optimized out>
border = {
left = 0,
right = 0,
top = 0,
bottom = 0
}
menu_bar = <optimized out>
menu_shell = <optimized out>
priv = <optimized out>
child = <optimized out>
children = <optimized out>
remaining_space = {
x = 0,
y = <optimized out>,
width = 443,
height = 24
}
border_width = <optimized out>
requested_sizes = 0xe53090
toggle_size = 0
i = <optimized out>
__FUNCTION__ = "gtk_menu_bar_size_allocate"
#4 0x00007ffff540d233 in g_cclosure_marshal_VOID__BOXEDv (closure=0x1672600, return_value=<optimized out>, instance=<optimized out>, args=<optimized out>,
marshal_data=<optimized out>, n_params=<optimized out>, param_types=0x1603f50) at /tmp/buildd/glib2.0-2.42.1/./gobject/gmarshal.c:1160
cc = 0x1672600
data1 = <optimized out>
data2 = <optimized out>
---Type <return> to continue, or q <return> to quit---
callback = <optimized out>
arg0 = 0x7fffffffbb20
args_copy = {{
gp_offset = 32,
fp_offset = 48,
overflow_arg_area = 0x7fffffffbac0,
reg_save_area = 0x7fffffffba00
}}
#5 0x00007ffff540a3c2 in _g_closure_invoke_va (closure=0x7ffff6db7edf, closure@entry=0x1672600, return_value=0x8, return_value@entry=0x0, instance=0x7ffff5185e25,
instance@entry=0x199a400, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args@entry=0x7fffffffb9e0, n_params=-153018873, param_types=0x1682470)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:831
marshal = 0x0
marshal_data = 0x7ffff6e11e07
__FUNCTION__ = "_g_closure_invoke_va"
#6 0x00007ffff5424087 in g_signal_emit_valist (instance=0x199a400, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffb9e0)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3218
return_accu = <optimized out>
accu = {
g_type = 0,
data = {{
v_int = 0,
v_uint = 0,
v_long = 0,
v_ulong = 0,
v_int64 = 0,
v_uint64 = 0,
v_float = 0,
v_double = 0,
v_pointer = 0x0
}, {
v_int = 0,
v_uint = 0,
v_long = 0,
v_ulong = 0,
v_int64 = 0,
v_uint64 = 0,
v_float = 0,
v_double = 0,
v_pointer = 0x0
}}
}
accumulator = 0x0
emission = {
next = 0x7fffffffbe50,
instance = 0x199a400,
ihint = {
signal_id = 10,
detail = 0,
run_type = G_SIGNAL_RUN_FIRST
---Type <return> to continue, or q <return> to quit---
},
state = EMISSION_RUN,
chain_type = 24923888
}
signal_id = 10
instance_type = <optimized out>
emission_return = {
g_type = 0,
data = {{
v_int = 0,
v_uint = 0,
v_long = 0,
v_ulong = 0,
v_int64 = 0,
v_uint64 = 0,
v_float = 0,
v_double = 0,
v_pointer = 0x0
}, {
v_int = 0,
v_uint = 0,
v_long = 0,
v_ulong = 0,
v_int64 = 0,
v_uint64 = 0,
v_float = 0,
v_double = 0,
v_pointer = 0x0
}}
}
rtype = 4
static_scope = 0
fastpath_handler = <optimized out>
closure = 0x1672600
run_type = <optimized out>
l = <optimized out>
fastpath = <optimized out>
instance_and_params = <optimized out>
signal_return_type = <optimized out>
param_values = <optimized out>
i = <optimized out>
n_params = <optimized out>
__FUNCTION__ = "g_signal_emit_valist"
#7 0x00007ffff54249df in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3365
var_args = {{
gp_offset = 24,
fp_offset = 48,
overflow_arg_area = 0x7fffffffbac0,
---Type <return> to continue, or q <return> to quit---
reg_save_area = 0x7fffffffba00
}}
#8 0x00007ffff6d67de7 in gtk_widget_size_allocate_with_baseline (widget=0x199a400, allocation=0x0, baseline=-1) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwidget.c:6075
priv = 0x199a320
real_allocation = {
x = 0,
y = 0,
width = 443,
height = 24
}
old_clip = {
x = 0,
y = 0,
width = 452,
height = 24
}
adjusted_allocation = {
x = 0,
y = 0,
width = 443,
height = 24
}
size_changed = 1
baseline_changed = 0
position_changed = 0
natural_width = 452
natural_height = 24
dummy = 32767
min_width = 452
min_height = 24
__FUNCTION__ = "gtk_widget_size_allocate_with_baseline"
#9 0x00007ffff6b3e21d in gtk_box_size_allocate_no_center (widget=0x7fffdc00a660, allocation=0x7fffffffc050) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkbox.c:800
box = 0x7fffdc00a660
private = 0x7fffdc00a540
child = 0x1b05480
children = 0x18512c0
nvis_children = 3
nexpand_children = 1
direction = GTK_TEXT_DIR_LTR
child_allocation = {
x = 0,
y = 0,
width = 443,
height = 24
}
sizes = 0x7fffffffbba0
child_minimum_baseline = 0
child_natural_baseline = 0
minimum_above = <optimized out>
---Type <return> to continue, or q <return> to quit---
natural_above = <optimized out>
minimum_below = <optimized out>
natural_below = <optimized out>
have_baseline = <optimized out>
baseline = -1
packing = GTK_PACK_START
size = <optimized out>
extra = <optimized out>
n_extra_widgets = <optimized out>
x = 0
y = 24
i = 0
child_size = <optimized out>
#10 0x00007ffff540d233 in g_cclosure_marshal_VOID__BOXEDv (closure=0x1672600, return_value=<optimized out>, instance=<optimized out>, args=<optimized out>,
marshal_data=<optimized out>, n_params=<optimized out>, param_types=0x1603f50) at /tmp/buildd/glib2.0-2.42.1/./gobject/gmarshal.c:1160
cc = 0x1672600
data1 = <optimized out>
data2 = <optimized out>
callback = <optimized out>
arg0 = 0x7fffffffc050
args_copy = {{
gp_offset = 32,
fp_offset = 48,
overflow_arg_area = 0x7fffffffbff0,
reg_save_area = 0x7fffffffbf30
}}
#11 0x00007ffff540a3c2 in _g_closure_invoke_va (closure=0x7ffff6db7edf, closure@entry=0x1672600, return_value=0x8, return_value@entry=0x0, instance=0x7ffff5185e25,
instance@entry=0x7fffdc00a660, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args@entry=0x7fffffffbf10, n_params=-153018873, param_types=0x1682470)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:831
marshal = 0x0
marshal_data = 0x7ffff6e11e07
__FUNCTION__ = "_g_closure_invoke_va"
#12 0x00007ffff5424087 in g_signal_emit_valist (instance=0x7fffdc00a660, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffbf10)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3218
return_accu = <optimized out>
accu = {
g_type = 0,
data = {{
v_int = 0,
v_uint = 0,
v_long = 0,
v_ulong = 0,
v_int64 = 0,
v_uint64 = 0,
v_float = 0,
v_double = 0,
v_pointer = 0x0
}, {
v_int = 0,
---Type <return> to continue, or q <return> to quit---
v_uint = 0,
v_long = 0,
v_ulong = 0,
v_int64 = 0,
v_uint64 = 0,
v_float = 0,
v_double = 0,
v_pointer = 0x0
}}
}
accumulator = 0x0
emission = {
next = 0x7fffffffc260,
instance = 0x7fffdc00a660,
ihint = {
signal_id = 10,
detail = 0,
run_type = G_SIGNAL_RUN_FIRST
},
state = EMISSION_RUN,
chain_type = 26249584
}
signal_id = 10
instance_type = <optimized out>
emission_return = {
g_type = 0,
data = {{
v_int = 0,
v_uint = 0,
v_long = 0,
v_ulong = 0,
v_int64 = 0,
v_uint64 = 0,
v_float = 0,
v_double = 0,
v_pointer = 0x0
}, {
v_int = 0,
v_uint = 0,
v_long = 0,
v_ulong = 0,
v_int64 = 0,
v_uint64 = 0,
v_float = 0,
v_double = 0,
v_pointer = 0x0
}}
}
rtype = 4
---Type <return> to continue, or q <return> to quit---
static_scope = 0
fastpath_handler = <optimized out>
closure = 0x1672600
run_type = <optimized out>
l = <optimized out>
fastpath = <optimized out>
instance_and_params = <optimized out>
signal_return_type = <optimized out>
param_values = <optimized out>
i = <optimized out>
n_params = <optimized out>
__FUNCTION__ = "g_signal_emit_valist"
#13 0x00007ffff54249df in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3365
var_args = {{
gp_offset = 24,
fp_offset = 48,
overflow_arg_area = 0x7fffffffbff0,
reg_save_area = 0x7fffffffbf30
}}
#14 0x00007ffff6d67de7 in gtk_widget_size_allocate_with_baseline (widget=0x7fffdc00a660, allocation=0x0, baseline=-1)
at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwidget.c:6075
priv = 0x7fffdc00a580
real_allocation = {
x = 0,
y = 0,
width = 443,
height = 627
}
old_clip = {
x = 0,
y = 0,
width = 452,
height = 627
}
adjusted_allocation = {
x = 0,
y = 0,
width = 443,
height = 627
}
size_changed = 1
baseline_changed = 0
position_changed = 0
natural_width = 533
natural_height = 156
dummy = 32767
min_width = 452
min_height = 156
---Type <return> to continue, or q <return> to quit---
__FUNCTION__ = "gtk_widget_size_allocate_with_baseline"
#15 0x00007ffff6d681aa in gtk_widget_size_allocate (widget=widget@entry=0x7fffdc00a660, allocation=allocation@entry=0x7fffffffc0d0)
at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwidget.c:6151
No locals.
#16 0x00007ffff6d7e4d3 in gtk_window_size_allocate (widget=<optimized out>, allocation=<optimized out>) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwindow.c:7309
window = <optimized out>
child = 0x7fffdc00a660
child_allocation = {
x = 0,
y = 0,
width = 443,
height = 627
}
#17 0x00007ffff540a245 in g_closure_invoke (closure=0x1672600, return_value=0x0, n_param_values=2, param_values=0x7fffffffc2d0, invocation_hint=0x7fffffffc270)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:768
marshal = <optimized out>
marshal_data = <optimized out>
in_marshal = 0
real_closure = 0x16725e0
__FUNCTION__ = "g_closure_invoke"
#18 0x00007ffff541b83b in signal_emit_unlocked_R (node=node@entry=0x1603ee0, detail=detail@entry=0, instance=instance@entry=0x1996240,
emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffc2d0) at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3483
accumulator = 0x0
emission = {
next = 0x7fffffffc840,
instance = 0x1996240,
ihint = {
signal_id = 10,
detail = 0,
run_type = G_SIGNAL_RUN_FIRST
},
state = EMISSION_RUN,
chain_type = 23647328
}
handler_list = <optimized out>
return_accu = 0x0
accu = {
g_type = 0,
data = {{
v_int = 0,
v_uint = 0,
v_long = 0,
v_ulong = 0,
v_int64 = 0,
v_uint64 = 0,
v_float = 0,
v_double = 0,
v_pointer = 0x0
}, {
---Type <return> to continue, or q <return> to quit---
v_int = 0,
v_uint = 0,
v_long = 0,
v_ulong = 0,
v_int64 = 0,
v_uint64 = 0,
v_float = 0,
v_double = 0,
v_pointer = 0x0
}}
}
signal_id = 10
max_sequential_handler_number = 11502
return_value_altered = <optimized out>
#19 0x00007ffff5424778 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffc460)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3309
instance_and_params = 0x7fffffffc2d0
signal_return_type = <optimized out>
param_values = 0x7fffffffc2e8
i = <optimized out>
n_params = <optimized out>
__FUNCTION__ = "g_signal_emit_valist"
#20 0x00007ffff54249df in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3365
var_args = {{
gp_offset = 32,
fp_offset = 48,
overflow_arg_area = 0x7fffffffc540,
reg_save_area = 0x7fffffffc480
}}
#21 0x00007ffff6d67de7 in gtk_widget_size_allocate_with_baseline (widget=0x1996240, allocation=0x0, baseline=-1) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwidget.c:6075
priv = 0x1996160
real_allocation = {
x = 0,
y = 0,
width = 443,
height = 627
}
old_clip = {
x = 0,
y = 0,
width = 452,
height = 627
}
adjusted_allocation = {
x = 0,
y = 0,
width = 443,
height = 627
---Type <return> to continue, or q <return> to quit---
}
size_changed = 1
baseline_changed = 0
position_changed = 0
natural_width = 533
natural_height = 156
dummy = -388717296
min_width = 452
min_height = 156
__FUNCTION__ = "gtk_widget_size_allocate_with_baseline"
#22 0x00007ffff6d681aa in gtk_widget_size_allocate (widget=widget@entry=0x1996240, allocation=allocation@entry=0x7fffffffc690)
at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwidget.c:6151
No locals.
#23 0x00007ffff6d78811 in gtk_window_move_resize (window=0x1996240) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwindow.c:9147
allocation = {
x = 0,
y = 0,
width = 443,
height = 627
}
new_flags = 106
current_width = 443
priv = 0x1996010
widget = 0x1996240
info = 0x1b2a910
new_geometry = {
min_width = 452,
min_height = 156,
max_width = 0,
max_height = 0,
base_width = 38,
base_height = 87,
width_inc = 9,
height_inc = 18,
min_aspect = 0,
max_aspect = 0,
win_gravity = GDK_GRAVITY_NORTH_WEST
}
new_request = {
x = 0,
y = 0,
width = 452,
height = 627
}
configure_request_pos_changed = 0
hints_changed = <optimized out>
current_height = <optimized out>
container = 0x1996240
gdk_window = 0x1707240
---Type <return> to continue, or q <return> to quit---
configure_request_size_changed = 0
saved_last_info = {
geometry = {
min_width = 452,
min_height = 156,
max_width = 0,
max_height = 0,
base_width = 38,
base_height = 87,
width_inc = 9,
height_inc = 18,
min_aspect = <optimized out>,
max_aspect = <optimized out>,
win_gravity = <optimized out>
},
flags = <optimized out>,
configure_request = {
x = <optimized out>,
y = <optimized out>,
width = <optimized out>,
height = <optimized out>
}
}
#24 gtk_window_check_resize (container=0x1996240) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwindow.c:7916
No locals.
#25 0x00007ffff540a474 in _g_closure_invoke_va (closure=0x7ffff6db7edf, closure@entry=0x167b5c0, return_value=0x8, return_value@entry=0x0, instance=0x7ffff5185e25,
instance@entry=0x1996240, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args@entry=0x7fffffffc900, n_params=-153018873, param_types=0x1682470)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:831
marshal = 0x0
marshal_data = 0x7ffff6e11e07
__FUNCTION__ = "_g_closure_invoke_va"
#26 0x00007ffff5424087 in g_signal_emit_valist (instance=0x1996240, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffc900)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3218
return_accu = <optimized out>
accu = {
g_type = 0,
data = {{
v_int = 0,
v_uint = 0,
v_long = 0,
v_ulong = 0,
v_int64 = 0,
v_uint64 = 0,
v_float = 0,
v_double = 0,
v_pointer = 0x0
}, {
v_int = 0,
v_uint = 0,
---Type <return> to continue, or q <return> to quit---
v_long = 0,
v_ulong = 0,
v_int64 = 0,
v_uint64 = 0,
v_float = 0,
v_double = 0,
v_pointer = 0x0
}}
}
accumulator = 0x0
emission = {
next = 0x7fffffffcb20,
instance = 0x1996240,
ihint = {
signal_id = 74,
detail = 0,
run_type = G_SIGNAL_RUN_LAST
},
state = EMISSION_RUN,
chain_type = 23647328
}
signal_id = 74
instance_type = <optimized out>
emission_return = {
g_type = 0,
data = {{
v_int = 0,
v_uint = 0,
v_long = 0,
v_ulong = 0,
v_int64 = 0,
v_uint64 = 0,
v_float = 0,
v_double = 0,
v_pointer = 0x0
}, {
v_int = 0,
v_uint = 0,
v_long = 0,
v_ulong = 0,
v_int64 = 0,
v_uint64 = 0,
v_float = 0,
v_double = 0,
v_pointer = 0x0
}}
}
rtype = 4
static_scope = 0
---Type <return> to continue, or q <return> to quit---
fastpath_handler = <optimized out>
closure = 0x167b5c0
run_type = <optimized out>
l = <optimized out>
fastpath = <optimized out>
instance_and_params = <optimized out>
signal_return_type = <optimized out>
param_values = <optimized out>
i = <optimized out>
n_params = <optimized out>
__FUNCTION__ = "g_signal_emit_valist"
#27 0x00007ffff54249df in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3365
var_args = {{
gp_offset = 24,
fp_offset = 48,
overflow_arg_area = 0x7fffffffc9e0,
reg_save_area = 0x7fffffffc920
}}
#28 0x00007ffff6b821fc in gtk_container_idle_sizer (clock=0x170b250, container=0x1996240) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkcontainer.c:1755
No locals.
#29 0x00007ffff540a474 in _g_closure_invoke_va (closure=0x7ffff6db7edf, closure@entry=0x1e53780, return_value=0x8, return_value@entry=0x0, instance=0x7ffff5185e25,
instance@entry=0x170b250, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args@entry=0x7fffffffcc48, n_params=-153018873, param_types=0x1682470)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:831
marshal = 0x0
marshal_data = 0x7ffff6e11e07
__FUNCTION__ = "_g_closure_invoke_va"
#30 0x00007ffff5424087 in g_signal_emit_valist (instance=0x170b250, signal_id=<optimized out>, detail=0, var_args=0x7fffffffcc48)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3218
return_accu = <optimized out>
accu = {
g_type = 0,
data = {{
v_int = 0,
v_uint = 0,
v_long = 0,
v_ulong = 0,
v_int64 = 0,
v_uint64 = 0,
v_float = 0,
v_double = 0,
v_pointer = 0x0
}, {
v_int = 0,
v_uint = 0,
v_long = 0,
v_ulong = 0,
v_int64 = 0,
v_uint64 = 0,
---Type <return> to continue, or q <return> to quit---
v_float = 0,
v_double = 0,
v_pointer = 0x0
}}
}
accumulator = 0x0
emission = {
next = 0x0,
instance = 0x170b250,
ihint = {
signal_id = 140,
detail = 0,
run_type = G_SIGNAL_RUN_FIRST
},
state = EMISSION_RUN,
chain_type = 24157520
}
signal_id = 140
instance_type = <optimized out>
emission_return = {
g_type = 0,
data = {{
v_int = 0,
v_uint = 0,
v_long = 0,
v_ulong = 0,
v_int64 = 0,
v_uint64 = 0,
v_float = 0,
v_double = 0,
v_pointer = 0x0
}, {
v_int = 0,
v_uint = 0,
v_long = 0,
v_ulong = 0,
v_int64 = 0,
v_uint64 = 0,
v_float = 0,
v_double = 0,
v_pointer = 0x0
}}
}
rtype = 4
static_scope = 0
fastpath_handler = <optimized out>
closure = 0x1e53780
run_type = <optimized out>
l = <optimized out>
---Type <return> to continue, or q <return> to quit---
fastpath = <optimized out>
instance_and_params = <optimized out>
signal_return_type = <optimized out>
param_values = <optimized out>
i = <optimized out>
n_params = <optimized out>
__FUNCTION__ = "g_signal_emit_valist"
#31 0x00007ffff5424f2a in g_signal_emit_by_name (instance=0x7ffff6db7edf, instance@entry=0x170b250, detailed_signal=0x8 <error: Cannot access memory at address 0x8>,
detailed_signal@entry=0x7ffff681b736 "layout") at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3405
var_args = {{
gp_offset = 16,
fp_offset = 48,
overflow_arg_area = 0x7fffffffcd80,
reg_save_area = 0x7fffffffcc90
}}
detail = 0
signal_id = 140
__FUNCTION__ = "g_signal_emit_by_name"
#32 0x00007ffff67b5974 in gdk_frame_clock_paint_idle (data=0x170b250) at /tmp/buildd/gtk+3.0-3.14.5/./gdk/gdkframeclockidle.c:408
iter = 1
clock = 0x170b250
clock_idle = 0x170b250
priv = 0x170b170
skip_to_resume_events = 0
timings = 0x1d9dcc0
#33 0x00007ffff67a7e78 in gdk_threads_dispatch (data=0x1860b40, data@entry=<error reading variable: value has been optimized out>)
at /tmp/buildd/gtk+3.0-3.14.5/./gdk/gdk.c:654
dispatch = 0x1860b40
ret = 0
#34 0x00007ffff5135613 in g_timeout_dispatch (source=0x1e58820, callback=<optimized out>, user_data=<optimized out>) at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:4520
timeout_source = 0x1e58820
again = <optimized out>
#35 0x00007ffff5134b6d in g_main_dispatch (context=0x16eacf0) at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3111
dispatch = 0x7ffff5135600 <g_timeout_dispatch>
prev_source = 0x0
was_in_call = 0
user_data = 0x1860b40
callback = 0x7ffff67a7e50 <gdk_threads_dispatch>
cb_funcs = <optimized out>
cb_data = 0x1c8fec0
need_destroy = <optimized out>
source = 0x1e58820
current = 0x170f5c0
i = 0
#36 g_main_context_dispatch (context=context@entry=0x16eacf0) at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3710
No locals.
#37 0x00007ffff5134f48 in g_main_context_iterate (context=context@entry=0x16eacf0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3781
max_priority = 120
---Type <return> to continue, or q <return> to quit---
timeout = 0
some_ready = 1
nfds = <optimized out>
allocated_nfds = 3
fds = 0x17f6c30
#38 0x00007ffff5134ffc in g_main_context_iteration (context=0x16eacf0, context@entry=0x0, may_block=may_block@entry=1) at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3842
retval = <optimized out>
#39 0x00007ffff6c2dcc5 in gtk_main_iteration () at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkmain.c:1308
No locals.
#40 0x0000000000545c63 in XTread_socket (terminal=0x12fdb80, hold_quit=0x7fffffffcf60) at xterm.c:8775
count = 0
event_found = false
dpyinfo = 0x1912800
#41 0x0000000000592262 in gobble_input () at keyboard.c:6771
nr = 0
hold_quit = {
kind = NO_EVENT,
part = scroll_bar_nowhere,
code = 0,
modifiers = 0,
x = 0,
y = 0,
timestamp = 0,
frame_or_window = 0,
arg = 0
}
next = 0x0
nread = 0
err = false
t = 0x12fdb80
#42 0x00000000005927e7 in handle_async_input () at keyboard.c:7023
nread = 0
#43 0x0000000000592806 in process_pending_signals () at keyboard.c:7037
No locals.
#44 0x0000000000604c49 in Fmake_list (length=0, init=0) at alloc.c:2705
val = 31958179
size = 0
#45 0x00000000006361fb in concat (nargs=1, args=0x7fffffffd1a8, target_type=Lisp_Cons, last_special=false) at fns.c:633
val = 0
tail = 0
this = 22459043
toindex = 0
toindex_byte = 0
result_len = 1
result_len_byte = 1
argnum = 1
last_tail = 0
prev = 0
some_multibyte = false
---Type <return> to continue, or q <return> to quit---
textprops = 0x0
num_textprops = 0
sa_avail = 16384
sa_count = 3
sa_must_free = false
#46 0x0000000000635b9a in Fcopy_sequence (arg=22459043) at fns.c:501
No locals.
#47 0x000000000058c928 in timer_check () at keyboard.c:4447
nexttime = {
tv_sec = 0,
tv_nsec = 0
}
timers = 0
idle_timers = 0
tem = 0
#48 0x000000000058a0f6 in readable_events (flags=1) at keyboard.c:3304
No locals.
#49 0x00000000005920ac in get_input_pending (flags=1) at keyboard.c:6686
No locals.
#50 0x0000000000599894 in detect_input_pending_run_timers (do_display=true) at keyboard.c:9817
old_timers_run = 6
#51 0x000000000068a0db in wait_reading_process_output (time_limit=0, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=0, wait_proc=0x0, just_wait_proc=0)
at process.c:4963
old_timers_run = 6
old_buffer = 0xde1100
old_window = 20934853
leave = false
process_skipped = false
channel = 0
nfds = 1
Available = {
fds_bits = {512, 0 <repeats 15 times>}
}
Writeok = {
fds_bits = {0 <repeats 16 times>}
}
check_write = true
check_delay = 0
no_avail = false
xerrno = 11
proc = 140737488344704
timeout = {
tv_sec = 0,
tv_nsec = 0
}
end_time = {
tv_sec = 51926,
tv_nsec = 526406277
}
---Type <return> to continue, or q <return> to quit---
timer_delay = {
tv_sec = 0,
tv_nsec = 242146435
}
got_output_end_time = {
tv_sec = 1448483268,
tv_nsec = 894015374
}
wait = INFINITY
got_some_output = -1
count = 2
now = {
tv_sec = 0,
tv_nsec = -1
}
#52 0x000000000058b16c in kbd_buffer_get_event (kbp=0x7fffffffd818, used_mouse_menu=0x7fffffffddff, end_time=0x0) at keyboard.c:3795
do_display = true
obj = 893985407
#53 0x0000000000586701 in read_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffffdbc0, used_mouse_menu=0x7fffffffddff) at keyboard.c:2121
c = 0
save_jump = {{
__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0},
__mask_was_saved = 0,
__saved_mask = {
__val = {0 <repeats 16 times>}
}
}}
kb = 0x0
#54 0x00000000005869d0 in read_decoded_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffffdbc0, prev_event=0, used_mouse_menu=0x7fffffffddff)
at keyboard.c:2184
nextevt = 14249584
frame = 0x7fffffffda70
terminal = 0x0
events = {140737488345584, 14249584, 0, 0, 140737488345584, 5742676, 0, 31935987, 140737488345648, 5808618, 935, 4294967296, 0, 5742676, 20934848, 0}
n = 0
#55 0x000000000058863c in read_char (commandflag=1, map=30806627, prev_event=0, used_mouse_menu=0x7fffffffddff, end_time=0x0) at keyboard.c:2779
c = 0
jmpcount = 2
local_getcjmp = {{
__jmpbuf = {0, -308247075226988984, 21848269, 44304, 0, 0, -308247075057119672, 308247691226828360},
__mask_was_saved = 0,
__saved_mask = {
__val = {14249584, 140737488346176, 0, 140737488346176, 5742676, 18912080, 14249584, 140737488346320, 0, 140737488346224, 5742676, 0, 19261859,
140737488346320, 6497538, 0}
}
}}
save_jump = {{
__jmpbuf = {0, 0, 0, 25769803776, 14553344, 140737488345928, 5749423, 25769803776},
__mask_was_saved = 14553349,
---Type <return> to continue, or q <return> to quit---
__saved_mask = {
__val = {140737488345960, 14553344, 140737488345952, 5749640, 25784357125, 14553344, 140737488346008, 5749423, 25769833104, 14553349, 6966294, 14553344,
140737488346032, 5749640, 14553349, 140737488346064}
}
}}
tem = 535296
save = 0
previous_echo_area_message = 0
also_record = 0
reread = false
recorded = false
polling_stopped_here = true
orig_kboard = 0x171ac90
#56 0x0000000000597c93 in read_key_sequence (keybuf=0x7fffffffdfb0, bufsize=30, prompt=0, dont_downcase_last=false, can_return_switch_frame=true,
fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9018
interrupted_kboard = 0x171ac90
interrupted_frame = 0x13f60b0
key = 25774401020
used_mouse_menu = false
echo_local_start = 0
last_real_key_start = 0
keys_local_start = 0
new_binding = 5749423
count = 2
t = 0
echo_start = 0
keys_start = 0
current_binding = 30806627
first_event = 0
first_unbound = 31
mock_input = 0
fkey = {
parent = 18643683,
map = 18643683,
start = 0,
end = 0
}
keytran = {
parent = 14507587,
map = 14507587,
start = 0,
end = 0
}
indec = {
parent = 18644019,
map = 18644019,
start = 0,
end = 0
}
---Type <return> to continue, or q <return> to quit---
shift_translated = false
delayed_switch_frame = 0
original_uppercase = 5749423
original_uppercase_position = -1
dummyflag = false
starting_buffer = 0xde1100
fake_prefixed_keys = 0
#57 0x00000000005846af in command_loop_1 () at keyboard.c:1343
cmd = 18912
keybuf = {7068, 28272, 140737488347120, 6356275, 14086960, 0, 5749288, 0, 140737488347216, 6359201, 0, 28272, 0, 14249584, 14086960, 0, 140737488347216,
5742676, 140737488347248, 0, 140737488347312, 6497538, 14700803, 14249584, 140737488347312, 0, 140737488347296, 5742676, 14277856, 0}
i = 0
prev_modiff = 0
prev_buffer = 0x0
already_adjusted = false
#58 0x000000000062d0e3 in internal_condition_case (bfun=0x58426d <command_loop_1>, handlers=18912, hfun=0x5838db <cmd_error>) at eval.c:1309
val = 14700803
c = 0x165cc10
#59 0x0000000000583e9b in command_loop_2 (ignore=0) at keyboard.c:1086
val = 0
#60 0x000000000062c68d in internal_catch (tag=45696, func=0x583e72 <command_loop_2>, arg=0) at eval.c:1074
val = 0
c = 0x165cae0
#61 0x0000000000583e3b in command_loop () at keyboard.c:1065
No locals.
#62 0x00000000005833ba in recursive_edit_1 () at keyboard.c:671
count = 1
val = 140737488347696
#63 0x00000000005835c5 in Frecursive_edit () at keyboard.c:742
count = 0
buffer = 0
#64 0x00000000005813d8 in main (argc=2, argv=0x7fffffffe438) at emacs.c:1656
dummy = 140737488347872
stack_bottom_variable = 0 '\000'
do_initial_setlocale = true
dumping = false
skip_args = 0
rlim = {
rlim_cur = 8720000,
rlim_max = 18446744073709551615
}
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = 0x0
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: 25.0.50; Running dired changes frame width, gtk_distribute_natural_allocation throws assertion
2015-11-24 16:48 ` David Engster
@ 2015-11-24 19:26 ` martin rudalics
2015-11-25 16:15 ` David Engster
0 siblings, 1 reply; 97+ messages in thread
From: martin rudalics @ 2015-11-24 19:26 UTC (permalink / raw)
To: David Engster; +Cc: 22000
> Yes. But at least I know now what really triggers this problem: GTK
> throws this assertion when the menubar is not completely visible. This
> is also why running Dired triggers this, because it adds a bunch of
> additional menu entries. The frame is then resized so that the menu-bar
> fits.
Magnificent! Easy to trigger here by continuously narrowing the frame
until a menubar item disappears. And starting dired from a fairly
narrow frame with the menubar fully visible resizes the frame so that
all menubar items are visible. Thanks for finding the cause of this.
And obviously this is Bug#15700 ;-)
I don't think we can/should do anything about this. But at least we
have to document it somewhere. Any ideas?
martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: 25.0.50; Running dired changes frame width, gtk_distribute_natural_allocation throws assertion
2015-11-24 19:26 ` martin rudalics
@ 2015-11-25 16:15 ` David Engster
2015-11-25 17:48 ` martin rudalics
0 siblings, 1 reply; 97+ messages in thread
From: David Engster @ 2015-11-25 16:15 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000
martin rudalics writes:
>> Yes. But at least I know now what really triggers this problem: GTK
>> throws this assertion when the menubar is not completely visible. This
>> is also why running Dired triggers this, because it adds a bunch of
>> additional menu entries. The frame is then resized so that the menu-bar
>> fits.
>
> Magnificent! Easy to trigger here by continuously narrowing the frame
> until a menubar item disappears. And starting dired from a fairly
> narrow frame with the menubar fully visible resizes the frame so that
> all menubar items are visible. Thanks for finding the cause of this.
>
> And obviously this is Bug#15700 ;-)
I really need to improve my search-fu...
> I don't think we can/should do anything about this.
Not sure about the "can", but I think we definitely should. The
dired-thing is already pretty annoying for people like my co-worker who
are very adamant about having an Emacs frame that is *exactly* 80
characters wide. He has to resize the frame every time he leaves Dired.
Also, after some more testing, it seems pretty clear that the frame size
is battled out between GTK and Emacs when you make the width smaller
than the menu-bar. If you resize with the mouse, it depends on the
window manager what exactly happens, but I've seen two things:
- with 'wmii', the window simply snaps back to the width that's needed
by the menu bar
- with 'i3', I can resize to a smaller width with the mouse, but during
the resize I see flickering to the menu-bar width
Also, it seems to be impossible to programatically set a frame width
that is smaller than the menu-bar. `set-frame-width' doesn't work,
neither does `initial-frame-alist' or even the '-geometry' switch.
Unfortunately, I'm not very familiar with GTK. My guess is that you
would somehow have to catch the 'size-allocate' signal and do The Right
Thing in the callback, but my hacks so far were not successful.
> But at least we have to document it somewhere. Any ideas?
For starters, I think this should be documented in the Emacs manual
about frame parameters and in functions/variables like `set-frame-width'
and `initial-frame-alist'.
-David
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: 25.0.50; Running dired changes frame width, gtk_distribute_natural_allocation throws assertion
2015-11-25 16:15 ` David Engster
@ 2015-11-25 17:48 ` martin rudalics
2015-11-25 19:00 ` David Engster
0 siblings, 1 reply; 97+ messages in thread
From: martin rudalics @ 2015-11-25 17:48 UTC (permalink / raw)
To: David Engster; +Cc: 22000
>> And obviously this is Bug#15700 ;-)
>
> I really need to improve my search-fu...
I could have noticed sooner too. Google also lists:
https://bugzilla.redhat.com/show_bug.cgi?id=881760
https://lists.gnu.org/archive/html/emacs-devel/2012-11/msg00276.html
https://bbs.archlinux.org/viewtopic.php?id=168847
https://cygwin.com/ml/cygwin/2013-07/msg00070.html
>> I don't think we can/should do anything about this.
>
> Not sure about the "can", but I think we definitely should. The
> dired-thing is already pretty annoying for people like my co-worker who
> are very adamant about having an Emacs frame that is *exactly* 80
> characters wide. He has to resize the frame every time he leaves Dired.
>
> Also, after some more testing, it seems pretty clear that the frame size
> is battled out between GTK and Emacs when you make the width smaller
> than the menu-bar. If you resize with the mouse, it depends on the
> window manager what exactly happens, but I've seen two things:
>
> - with 'wmii', the window simply snaps back to the width that's needed
> by the menu bar
>
> - with 'i3', I can resize to a smaller width with the mouse, but during
> the resize I see flickering to the menu-bar width
>
> Also, it seems to be impossible to programatically set a frame width
> that is smaller than the menu-bar. `set-frame-width' doesn't work,
> neither does `initial-frame-alist' or even the '-geometry' switch.
Here with xfce ‘set-frame-width’ and ‘default-frame-alist’ both crop the
menubar.
> Unfortunately, I'm not very familiar with GTK. My guess is that you
> would somehow have to catch the 'size-allocate' signal and do The Right
> Thing in the callback, but my hacks so far were not successful.
If I'm not mistaken the problem should happen in one of the two
gtk_distribute_natural_allocation calls of gtk_menu_bar_size_allocate.
But create_menus in gtkutil.c has this
/* Set width of menu bar to a small value so it doesn't enlarge
a small initial frame size. The width will be set to the
width of the frame later on when it is added to a container.
height -1: Natural height. */
gtk_widget_set_size_request (wmenu, 1, -1);
I have no idea yet how these are related and when the "width will be set".
> For starters, I think this should be documented in the Emacs manual
> about frame parameters and in functions/variables like `set-frame-width'
> and `initial-frame-alist'.
Could people test this with their favorite window managers?
martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: 25.0.50; Running dired changes frame width, gtk_distribute_natural_allocation throws assertion
2015-11-25 17:48 ` martin rudalics
@ 2015-11-25 19:00 ` David Engster
2015-11-26 8:22 ` martin rudalics
0 siblings, 1 reply; 97+ messages in thread
From: David Engster @ 2015-11-25 19:00 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000
martin rudalics writes:
>>> And obviously this is Bug#15700 ;-)
>>
>> I really need to improve my search-fu...
>
> I could have noticed sooner too. Google also lists:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=881760
>
> https://lists.gnu.org/archive/html/emacs-devel/2012-11/msg00276.html
>
> https://bbs.archlinux.org/viewtopic.php?id=168847
>
> https://cygwin.com/ml/cygwin/2013-07/msg00070.html
I've actually found most of those, as well as bug #12234, but I think
that one was a problem only with Unity.
>> Also, it seems to be impossible to programatically set a frame width
>> that is smaller than the menu-bar. `set-frame-width' doesn't work,
>> neither does `initial-frame-alist' or even the '-geometry' switch.
>
> Here with xfce ‘set-frame-width’ and ‘default-frame-alist’ both crop the
> menubar.
That's weird. I just tested with 'icewm' and saw the same behavior as in
'i3' (flickering during resize and (set-frame-width nil 10) not
working). Maybe it also depends on the exact GTK3 version?
>> Unfortunately, I'm not very familiar with GTK. My guess is that you
>> would somehow have to catch the 'size-allocate' signal and do The Right
>> Thing in the callback, but my hacks so far were not successful.
>
> If I'm not mistaken the problem should happen in one of the two
> gtk_distribute_natural_allocation calls of gtk_menu_bar_size_allocate.
>
> But create_menus in gtkutil.c has this
>
> /* Set width of menu bar to a small value so it doesn't enlarge
> a small initial frame size. The width will be set to the
> width of the frame later on when it is added to a container.
> height -1: Natural height. */
> gtk_widget_set_size_request (wmenu, 1, -1);
>
> I have no idea yet how these are related and when the "width will be set".
I think the final width is set when container containing the menu widget
is actually displayed. The code is pretty opaque to me - I guess we
can't just use a plain gtk menu_bar because we need to add/remove menu
items at runtime? Because any other GTK3 app I've tried did not have any
problem with cropping the menu bar during resize.
-David
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: 25.0.50; Running dired changes frame width, gtk_distribute_natural_allocation throws assertion
2015-11-25 19:00 ` David Engster
@ 2015-11-26 8:22 ` martin rudalics
0 siblings, 0 replies; 97+ messages in thread
From: martin rudalics @ 2015-11-26 8:22 UTC (permalink / raw)
To: David Engster; +Cc: 22000
>> Here with xfce ‘set-frame-width’ and ‘default-frame-alist’ both crop the
>> menubar.
>
> That's weird. I just tested with 'icewm' and saw the same behavior as in
> 'i3' (flickering during resize and (set-frame-width nil 10) not
> working). Maybe it also depends on the exact GTK3 version?
Mine is 3.4.2.
> I think the final width is set when container containing the menu widget
> is actually displayed. The code is pretty opaque to me - I guess we
> can't just use a plain gtk menu_bar because we need to add/remove menu
> items at runtime? Because any other GTK3 app I've tried did not have any
> problem with cropping the menu bar during resize.
At least that's the only reason I can think of why this problem seems to
predominantly hit Emacs.
martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2015-11-23 20:55 bug#22000: 25.0.50; Running dired changes frame width, gtk_distribute_natural_allocation throws assertion David Engster
2015-11-24 8:28 ` martin rudalics
@ 2018-07-15 18:09 ` Vivek Dasmohapatra
2018-07-16 7:28 ` martin rudalics
1 sibling, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-07-15 18:09 UTC (permalink / raw)
To: 22000
[-- Attachment #1: Type: TEXT/PLAIN, Size: 356 bytes --]
Tags: patch
This patch attempts to address the menu-bar interaction with the
frame size: I've been using it locally for a short while now.
It does make the menu bar taller than it was - This may be
addressable by using overlay scrollbars but there is currently
a bad focus interaction with those so the patch suppresses them
(overlay scrollbars) for now.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: TEXT/x-diff; name=0001-GTK3-menu-bars-force-frame-resizing-Bug-22000.patch, Size: 3911 bytes --]
From c00e61e01fb2c15516ab753897d6bd327845c1ae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vivek=20Das=C2=A0Mohapatra?= <vivek@collabora.com>
Date: Sun, 15 Jul 2018 18:59:59 +0100
Subject: [PATCH] GTK3 menu bars force frame resizing (Bug#22000)
Menu bars force the frame they are in to resize when the menu bar
width exceeds the frame width, both at the point the menu bar grows
past the frame width and whenever the gtk idle resize callback is
triggered.
The effect is that the user's frame width is effectively ignored, and
emacs will semi-predictably resize itself to accommodate the menu bar.
This effect can be suppressed by wrapping the menu bar in a scrollable
window.
---
src/gtkutil.c | 31 ++++++++++++++++++++++++++-----
src/xterm.h | 1 +
2 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/src/gtkutil.c b/src/gtkutil.c
index 69325ff00a..d954eca401 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -3461,6 +3461,7 @@ xg_update_frame_menubar (struct frame *f)
{
struct x_output *x = f->output_data.x;
GtkRequisition req;
+ GtkScrolledWindow *sw;
if (!x->menubar_widget || gtk_widget_get_mapped (x->menubar_widget))
return;
@@ -3470,12 +3471,30 @@ xg_update_frame_menubar (struct frame *f)
block_input ();
- gtk_box_pack_start (GTK_BOX (x->vbox_widget), x->menubar_widget,
- FALSE, FALSE, 0);
- gtk_box_reorder_child (GTK_BOX (x->vbox_widget), x->menubar_widget, 0);
+ /* Put the menu bar inside a scrolled window so that adding items
+ to the menu bar (such as when entering dired mode or activating
+ a minor more) does not trigger a frame resize:*/
+ x->menubar_viewport = gtk_scrolled_window_new(NULL, NULL);
+ sw = GTK_SCROLLED_WINDOW (x->menubar_viewport);
+
+ /* Leave the keyboard focus where it is when clicking the scrollwindow: */
+ gtk_widget_set_focus_on_click (GTK_WIDGET(sw), FALSE);
+
+ gtk_scrolled_window_set_policy (sw, GTK_POLICY_AUTOMATIC, GTK_POLICY_NEVER);
+
+ /* If we don't set this then the scrollable keeps focus when the user
+ interacts with the scrollbar, at least until the menubar is clicked.
+ Overlay scrolling is more compact but until the focus problem is fixed
+ it's not livable with. */
+ gtk_scrolled_window_set_overlay_scrolling (sw, FALSE);
+
+ gtk_container_add (GTK_CONTAINER (sw), x->menubar_widget);
+
+ gtk_box_pack_start (GTK_BOX (x->vbox_widget), GTK_WIDGET(sw), FALSE, FALSE, 0);
+ gtk_box_reorder_child (GTK_BOX (x->vbox_widget), GTK_WIDGET(sw), 0);
g_signal_connect (x->menubar_widget, "map", G_CALLBACK (menubar_map_cb), f);
- gtk_widget_show_all (x->menubar_widget);
+ gtk_widget_show_all (x->menubar_viewport);
gtk_widget_get_preferred_size (x->menubar_widget, NULL, &req);
if (FRAME_MENUBAR_HEIGHT (f) != req.height)
@@ -3498,9 +3517,11 @@ free_frame_menubar (struct frame *f)
{
block_input ();
- gtk_container_remove (GTK_CONTAINER (x->vbox_widget), x->menubar_widget);
+ gtk_container_remove (GTK_CONTAINER (x->menubar_viewport), x->menubar_widget);
+ gtk_container_remove (GTK_CONTAINER (x->vbox_widget), x->menubar_viewport);
/* The menubar and its children shall be deleted when removed from
the container. */
+ x->menubar_viewport = 0;
x->menubar_widget = 0;
FRAME_MENUBAR_HEIGHT (f) = 0;
adjust_frame_size (f, -1, -1, 2, 0, Qmenu_bar_lines);
diff --git a/src/xterm.h b/src/xterm.h
index 1849a5c953..9bf3d9778b 100644
--- a/src/xterm.h
+++ b/src/xterm.h
@@ -583,6 +583,7 @@ struct x_output
/* The widget used for laying out widgets horizontally. */
GtkWidget *hbox_widget;
/* The menubar in this frame. */
+ GtkWidget *menubar_viewport;
GtkWidget *menubar_widget;
/* The tool bar in this frame */
GtkWidget *toolbar_widget;
--
2.11.0
^ permalink raw reply related [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-07-15 18:09 ` bug#22000: Patch addressing the menu-bar frame-resize interaction Vivek Dasmohapatra
@ 2018-07-16 7:28 ` martin rudalics
2018-07-16 9:46 ` Vivek Dasmohapatra
0 siblings, 1 reply; 97+ messages in thread
From: martin rudalics @ 2018-07-16 7:28 UTC (permalink / raw)
To: Vivek Dasmohapatra, 22000
> This patch attempts to address the menu-bar interaction with the
> frame size: I've been using it locally for a short while now.
Thanks. 'gtk_widget_set_focus_on_click' is only available since GTK
3.20 and 'gtk_scrolled_window_set_overlay_scrolling' since 3.16 so
please condition your patch accordingly in order to allow compilation
with older versions (like mine).
Making the menu bar a "scrolled window" appears like a rather gross
hack to me and I think we should use it only as a last resort. Can
you tell what actually is different for a scrolled window in order to
not trigger auto-resizing of its parent?
I wonder why 'gtk_widget_set_size_request' does not handle this
problem in the first place. In 'create_menus' we do
wmenu = gtk_menu_bar_new ();
/* Set width of menu bar to a small value so it doesn't enlarge
a small initial frame size. The width will be set to the
width of the frame later on when it is added to a container.
height -1: Natural height. */
gtk_widget_set_size_request (wmenu, 1, -1);
Is it possible that this gets reset later and/or another such call is
needed when adding a new menu bar item? After all, you can set a
small initial width of a frame via 'default-frame-alist' so that the
menu bar is initially partially hidden/truncated. Right? So in
principle truncating should work but somehow breaks when we add items
to the menu bar.
Note that I can't really experiment with this because I don't get any
resizing here.
> It does make the menu bar taller than it was - This may be
> addressable by using overlay scrollbars but there is currently
> a bad focus interaction with those so the patch suppresses them
> (overlay scrollbars) for now.
How much taller does the menu bar get? By the possible height of a
horizontal scroll bar?
Thank you for working on this problem, martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-07-16 7:28 ` martin rudalics
@ 2018-07-16 9:46 ` Vivek Dasmohapatra
2018-07-16 19:58 ` Vivek Dasmohapatra
0 siblings, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-07-16 9:46 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000
On Mon, 16 Jul 2018, martin rudalics wrote:
> Making the menu bar a "scrolled window" appears like a rather gross
> hack to me and I think we should use it only as a last resort. Can
> you tell what actually is different for a scrolled window in order to
> not trigger auto-resizing of its parent?
Literally what the scrolled window is for, from what I can tell: Make
a widget that otherwise makes hard demands of its parent for space
allocation into a scrollable one.
> I wonder why 'gtk_widget_set_size_request' does not handle this
> problem in the first place. In 'create_menus' we do
> Is it possible that this gets reset later and/or another such call is
> needed when adding a new menu bar item? After all, you can set a
Yes, I've been digging through the code a bit and it looks like the
menu bar recalculates everything when its contents change. In addition
there's an idle callback which occasionally asks the menu bar what it
thinks its size is.
I was hoping to be able to figure out if this was controllable from
user code by comparing with the tool bar, which does not seem to
display this symptom, but no luck so far.
>> It does make the menu bar taller than it was - This may be
>> addressable by using overlay scrollbars but there is currently
>> a bad focus interaction with those so the patch suppresses them
>> (overlay scrollbars) for now.
>
> How much taller does the menu bar get? By the possible height of a
> horizontal scroll bar?
If you have overlay scrolling, no taller: If you don't, the height
of a scrollbar plus whatever spacing is defined for the scrollable
window by your gtk style (default: 3px).
> Thank you for working on this problem, martin
No problem, it's been annoying me for a few years now.
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-07-16 9:46 ` Vivek Dasmohapatra
@ 2018-07-16 19:58 ` Vivek Dasmohapatra
2018-07-17 7:48 ` martin rudalics
0 siblings, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-07-16 19:58 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000
[-- Attachment #1: Type: TEXT/PLAIN, Size: 662 bytes --]
I have #ifdef'd the calls you mentioned with GTK_CHECK_VERSION guards.
I also checked with one of the gnome/gtk devs and wrapping a
widget with strict ideas about its size is how you are supposed
to prevent its size from propagating: I suppose an alternative
would be some widget that doesn't resize or scroll at all,
but the basic approach would be the same.
I could not find a way to make overlay scrolbars behave, I think it's
probably a bug in overlay scrollbars since classic scrollbars behave
just fine: I don't think that will be a problem as 3.16 is when overlay
scrolling was introduced and that was also when the disabling function
was provided.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: TEXT/x-diff; name=0001-GTK3-menu-bars-force-frame-resizing-Bug-22000.patch, Size: 3999 bytes --]
From cd3e84356de102eab24e57042285c28ac2b2c970 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vivek=20Das=C2=A0Mohapatra?= <vivek@collabora.com>
Date: Sun, 15 Jul 2018 18:59:59 +0100
Subject: [PATCH] GTK3 menu bars force frame resizing (Bug#22000)
Menu bars force the frame they are in to resize when the menu bar
width exceeds the frame width, both at the point the menu bar grows
past the frame width and whenever the gtk idle resize callback is
triggered.
The effect is that the user's frame width is effectively ignored, and
emacs will semi-predictably resize itself to accommodate the menu bar.
This effect can be suppressed by wrapping the menu bar in a scrollable
window.
---
src/gtkutil.c | 34 +++++++++++++++++++++++++++++-----
src/xterm.h | 1 +
2 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/src/gtkutil.c b/src/gtkutil.c
index 69325ff00a..d16274f6ab 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -3461,6 +3461,7 @@ xg_update_frame_menubar (struct frame *f)
{
struct x_output *x = f->output_data.x;
GtkRequisition req;
+ GtkScrolledWindow *sw;
if (!x->menubar_widget || gtk_widget_get_mapped (x->menubar_widget))
return;
@@ -3470,12 +3471,33 @@ xg_update_frame_menubar (struct frame *f)
block_input ();
- gtk_box_pack_start (GTK_BOX (x->vbox_widget), x->menubar_widget,
- FALSE, FALSE, 0);
- gtk_box_reorder_child (GTK_BOX (x->vbox_widget), x->menubar_widget, 0);
+ /* Put the menu bar inside a scrolled window so that adding items
+ to the menu bar (such as when entering dired mode or activating
+ a minor more) does not trigger a frame resize:*/
+ x->menubar_viewport = gtk_scrolled_window_new(NULL, NULL);
+ sw = GTK_SCROLLED_WINDOW (x->menubar_viewport);
+ gtk_scrolled_window_set_policy (sw, GTK_POLICY_AUTOMATIC, GTK_POLICY_NEVER);
+
+ /* Leave the keyboard focus where it is when clicking the scrollwindow: */
+#if GTK_CHECK_VERSION (3, 20, 0)
+ gtk_widget_set_focus_on_click (GTK_WIDGET(sw), FALSE);
+#endif
+
+#if GTK_CHECK_VERSION (3, 16, 0)
+ /* If we don't set this then the scrollable keeps focus when the user
+ interacts with the scrollbar, at least until the menubar is clicked.
+ Overlay scrolling is more compact but until the focus problem is fixed
+ it's not livable with. */
+ gtk_scrolled_window_set_overlay_scrolling (sw, FALSE);
+#endif
+
+ gtk_container_add (GTK_CONTAINER (sw), x->menubar_widget);
+
+ gtk_box_pack_start (GTK_BOX (x->vbox_widget), GTK_WIDGET(sw), FALSE, FALSE, 0);
+ gtk_box_reorder_child (GTK_BOX (x->vbox_widget), GTK_WIDGET(sw), 0);
g_signal_connect (x->menubar_widget, "map", G_CALLBACK (menubar_map_cb), f);
- gtk_widget_show_all (x->menubar_widget);
+ gtk_widget_show_all (x->menubar_viewport);
gtk_widget_get_preferred_size (x->menubar_widget, NULL, &req);
if (FRAME_MENUBAR_HEIGHT (f) != req.height)
@@ -3498,9 +3520,11 @@ free_frame_menubar (struct frame *f)
{
block_input ();
- gtk_container_remove (GTK_CONTAINER (x->vbox_widget), x->menubar_widget);
+ gtk_container_remove (GTK_CONTAINER (x->menubar_viewport), x->menubar_widget);
+ gtk_container_remove (GTK_CONTAINER (x->vbox_widget), x->menubar_viewport);
/* The menubar and its children shall be deleted when removed from
the container. */
+ x->menubar_viewport = 0;
x->menubar_widget = 0;
FRAME_MENUBAR_HEIGHT (f) = 0;
adjust_frame_size (f, -1, -1, 2, 0, Qmenu_bar_lines);
diff --git a/src/xterm.h b/src/xterm.h
index 1849a5c953..9bf3d9778b 100644
--- a/src/xterm.h
+++ b/src/xterm.h
@@ -583,6 +583,7 @@ struct x_output
/* The widget used for laying out widgets horizontally. */
GtkWidget *hbox_widget;
/* The menubar in this frame. */
+ GtkWidget *menubar_viewport;
GtkWidget *menubar_widget;
/* The tool bar in this frame */
GtkWidget *toolbar_widget;
--
2.11.0
^ permalink raw reply related [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-07-16 19:58 ` Vivek Dasmohapatra
@ 2018-07-17 7:48 ` martin rudalics
2018-07-17 13:45 ` Vivek Dasmohapatra
0 siblings, 1 reply; 97+ messages in thread
From: martin rudalics @ 2018-07-17 7:48 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: 22000, David Engster
> I have #ifdef'd the calls you mentioned with GTK_CHECK_VERSION guards.
Thank you. It builds here now with GTK 3.4.2 and seems to have the
intended effect.
> I also checked with one of the gnome/gtk devs and wrapping a
> widget with strict ideas about its size is how you are supposed
> to prevent its size from propagating:
I suppose the menu bar is a widget we never want to resize with GTK
and we want to get clipped pixelwise which means that the last
(rightmost here) entry may be partially visible but opens on a mouse
click and shows its submenus. This contrasts with the tool bar where
we want a rightmost item either fit or be omitted, that is, never be
shown partially.
The major problem with your patch is that it completely breaks the
initial frame geometry at least here: The nominal (outer) height of
the initial frame (with emacs -Q) goes down from 749 to 731 pixels.
The height of the initial window goes down from 35 lines (630 pixels)
to 33 lines (595 pixels).
The height of the menu bar (calculated from the remaining components
because 'frame-geometry' sees no difference) seems to go up from 27 to
34 or 44 pixels which means an increase of 7 or 17 pixels. I leave it
to your imagination what kind of uproar such behavior might provoke in
this our community.
So unless mine is very isolated, at the very least we would have to
make the behavior optional in order to address the concerns of all
users wrt implicit menu bar resizing and the size occupied by the menu
bar. And we would have to fix the frame geometry calculations.
> I suppose an alternative
> would be some widget that doesn't resize or scroll at all,
> but the basic approach would be the same.
There should be some. I have no idea who is responsible for the tool
bar behavior but IIUC that should be the way to go for the menu bar
(with different clipping behavior, I suppose).
Could people who reported a similar behavior (see bugs 15700, 22898,
31626) test Vivek's patch? I'm not sure whether they get this message
automatically, debbugs merging has always escaped my comprehension.
David, are you listening?
martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-07-17 7:48 ` martin rudalics
@ 2018-07-17 13:45 ` Vivek Dasmohapatra
2018-07-17 19:02 ` Vivek Dasmohapatra
0 siblings, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-07-17 13:45 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, David Engster
> The major problem with your patch is that it completely breaks the
> initial frame geometry at least here: The nominal (outer) height of
> the initial frame (with emacs -Q) goes down from 749 to 731 pixels.
> The height of the initial window goes down from 35 lines (630 pixels)
> to 33 lines (595 pixels).
Working on it - should be a case of using the container instead of the
menu bar for calculations.
> There should be some. I have no idea who is responsible for the tool
> bar behavior but IIUC that should be the way to go for the menu bar
> (with different clipping behavior, I suppose).
I could be wrong but it seems to be an intrinsic difference between the
toolbar and the menubar. I'll see if I can figure it out.
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-07-17 13:45 ` Vivek Dasmohapatra
@ 2018-07-17 19:02 ` Vivek Dasmohapatra
2018-07-18 7:01 ` martin rudalics
0 siblings, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-07-17 19:02 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, David Engster
[-- Attachment #1: Type: TEXT/PLAIN, Size: 255 bytes --]
>> The height of the initial window goes down from 35 lines (630 pixels)
>> to 33 lines (595 pixels).
This patch (added on top of the previous one) should fix the frame
size calculation.
Still looking into whether there's a purely truncating solution.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: TEXT/x-diff; name=0002-GTK3-correct-frame-height-calculation-with-scrollabl.patch, Size: 1483 bytes --]
From eaae86389d2862dc10804f45161f07cb475b49a0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vivek=20Das=C2=A0Mohapatra?= <vivek@collabora.com>
Date: Tue, 17 Jul 2018 19:53:42 +0100
Subject: [PATCH 2/2] GTK3 - correct frame height calculation with scrollable
menu bars
The frame height calculation needs to be done based on the new
scrollable window that wraps the menu bars to be accurate.
---
src/gtkutil.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/gtkutil.c b/src/gtkutil.c
index d16274f6ab..dc78976d22 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -3445,7 +3445,11 @@ menubar_map_cb (GtkWidget *w, gpointer user_data)
{
GtkRequisition req;
struct frame *f = user_data;
- gtk_widget_get_preferred_size (w, NULL, &req);
+ struct x_output *x = f->output_data.x;
+
+ /* Use the menubar viewport for size if there is one: */
+ gtk_widget_get_preferred_size (x->menubar_viewport ?: w, NULL, &req);
+
if (FRAME_MENUBAR_HEIGHT (f) != req.height)
{
FRAME_MENUBAR_HEIGHT (f) = req.height;
@@ -3498,7 +3502,7 @@ xg_update_frame_menubar (struct frame *f)
g_signal_connect (x->menubar_widget, "map", G_CALLBACK (menubar_map_cb), f);
gtk_widget_show_all (x->menubar_viewport);
- gtk_widget_get_preferred_size (x->menubar_widget, NULL, &req);
+ gtk_widget_get_preferred_size (x->menubar_viewport, NULL, &req);
if (FRAME_MENUBAR_HEIGHT (f) != req.height)
{
--
2.11.0
^ permalink raw reply related [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-07-17 19:02 ` Vivek Dasmohapatra
@ 2018-07-18 7:01 ` martin rudalics
2018-07-18 7:07 ` martin rudalics
2018-07-18 10:39 ` Vivek Dasmohapatra
0 siblings, 2 replies; 97+ messages in thread
From: martin rudalics @ 2018-07-18 7:01 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: 22000, David Engster
> This patch (added on top of the previous one) should fix the frame size calculation.
Thanks. The calculations are OK now. It confirms my earlier claim
that here the menu bar size increases from 27 to 44 pixels so it
becomes exactly as high as the tool bar.
> Still looking into whether there's a purely truncating solution.
I think your idea of using a container window is the way to go. Now
suppose we used a non-scrolled container window to put the menu bar
in, get its size before updating the menu bar, update the menu bar and
make a gtk_widget_set_size request for that container window to
restore its previous size. Would that fail and why?
martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-07-18 7:01 ` martin rudalics
@ 2018-07-18 7:07 ` martin rudalics
2018-07-18 10:39 ` Vivek Dasmohapatra
1 sibling, 0 replies; 97+ messages in thread
From: martin rudalics @ 2018-07-18 7:07 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: 22000, David Engster
> I think your idea of using a container window is the way to go. Now
> suppose we used a non-scrolled container window to put the menu bar
> in, get its size before updating the menu bar, update the menu bar and
> make a gtk_widget_set_size request for that container window to
Probably this must be gdk_window_move_resize or else we would have to
set the policy of the container window to allow shrinking.
> restore its previous size. Would that fail and why?
martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-07-18 7:01 ` martin rudalics
2018-07-18 7:07 ` martin rudalics
@ 2018-07-18 10:39 ` Vivek Dasmohapatra
2018-07-19 8:19 ` martin rudalics
1 sibling, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-07-18 10:39 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, David Engster
> suppose we used a non-scrolled container window to put the menu bar
> in, get its size before updating the menu bar, update the menu bar and
> make a gtk_widget_set_size request for that container window to
> restore its previous size. Would that fail and why?
Depends on the behaviour of the container. The menu bar gets poked
to emit its size from time to time by an internal gtk callback
so if the container respects its wishes it will pop back to the larger
size semi-predictably (this behaviour can occasionally be seen in
the currently released emacs as that's how the hbox behaves).
So we'd need a container that didn't grant such space requests.
gtk fixed is close, but from its documentation has other
limitations we don't want (no RTL support).
You can turn scrollbars off in a scrolled window but unfortunately
this results in the scrolled window responding to size allocation
requests from its child.
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-07-18 10:39 ` Vivek Dasmohapatra
@ 2018-07-19 8:19 ` martin rudalics
2018-07-19 12:04 ` Vivek Dasmohapatra
0 siblings, 1 reply; 97+ messages in thread
From: martin rudalics @ 2018-07-19 8:19 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: 22000, David Engster
>> suppose we used a non-scrolled container window to put the menu bar
>> in, get its size before updating the menu bar, update the menu bar and
>> make a gtk_widget_set_size request for that container window to
>> restore its previous size. Would that fail and why?
>
> Depends on the behaviour of the container. The menu bar gets poked
> to emit its size from time to time by an internal gtk callback
Can you point me to where gtk does that?
> so if the container respects its wishes it will pop back to the larger
> size semi-predictably (this behaviour can occasionally be seen in
> the currently released emacs as that's how the hbox behaves).
I suppose the container respecting its wishes is that of the Emacs
frame's window. And if that container were a scrolled window, it
would not auto-resize. Do I reason correctly?
> So we'd need a container that didn't grant such space requests.
> gtk fixed is close, but from its documentation has other
> limitations we don't want (no RTL support).
I'm probably too silly to understand the semantics of containers: The
menu bar widget's size is not fixed so its RTL behavior (and the
font/translation issues gtkfixed talks about) would not be affected.
Only the "virtual" container we'd add would have fixed size but this
does not mean that it passes on the fixed size property to the menu
bar's widget. Inherently, this means that we would be cheating GTK
another time. Or am I wrong?
> You can turn scrollbars off in a scrolled window but unfortunately
> this results in the scrolled window responding to size allocation
> requests from its child.
This is incoherent, at least. Could we suppress horizontal scroll
bars separately in a scrolled window (because I think that these are
responsible for the height increase of the menu bar)?
martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-07-19 8:19 ` martin rudalics
@ 2018-07-19 12:04 ` Vivek Dasmohapatra
2018-07-20 8:14 ` martin rudalics
0 siblings, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-07-19 12:04 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, David Engster
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2259 bytes --]
> Can you point me to where gtk does that?
Backtrace (attached):
gdk_frame_clock_paint_idle
…
→ gtk_container_idle_sizer
…
→ gtk_distribute_natural_allocation
Is the path, I think.
> I suppose the container respecting its wishes is that of the Emacs
> frame's window. And if that container were a scrolled window, it
> would not auto-resize. Do I reason correctly?
Initially it's the box (vbox?) that the menubar is added to.
Not sure that's the top level widget.
> I'm probably too silly to understand the semantics of containers: The
> menu bar widget's size is not fixed so its RTL behavior (and the
> font/translation issues gtkfixed talks about) would not be affected.
I'm not overly familiar with GTK myself - I'm just going by the docs
for gtk fixed. You may be correct: I'm not going to speculate further
or try to understand the underlying code, I'm just going to try it :)
> Only the "virtual" container we'd add would have fixed size but this
> does not mean that it passes on the fixed size property to the menu
> bar's widget. Inherently, this means that we would be cheating GTK
> another time. Or am I wrong?
IIUC you are right - that's how you're supposed to do it - I just don't
know if there's a non-deprecated widget that does what we want.
Worst case scenario: If I grab the scrolled window class and mutilate it
till it does what we want, would you consider emacs carrying that widget
class in its code? It shouldn't change any of the build dependencies.
NOTE: FWIW even the hbox and vbox we are using are deprecated and have
been for a while, so this whole area of code is going to need to be
converted over to gtk grid at some point anyway.
>> You can turn scrollbars off in a scrolled window but unfortunately
>
> This is incoherent, at least. Could we suppress horizontal scroll
> bars separately in a scrolled window (because I think that these are
> responsible for the height increase of the menu bar)?
You can suppress the scrollbars independently, but that's what restores
the unwanted resizing behaviour in that direction: Suppress the vertical
scrollbar and suddenly vertical size requests are honoured, suppress
the horizontal and suddenly the menu bar can force the frame size again.
[-- Attachment #2: Type: TEXT/plain, Size: 64184 bytes --]
#0 0x00007f6478ab875b in raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
resultvar = 0
pid = <optimized out>
#1 0x00000000004f0184 in terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40) at emacs.c:381
No locals.
#2 0x0000000000508fd3 in emacs_abort () at sysdep.c:2247
No locals.
#3 0x000000000056463b in Fsignal (error_symbol=error_symbol@entry=28656, data=86599795) at eval.c:1478
conditions = <optimized out>
string = <optimized out>
real_error_symbol = 28656
clause = <optimized out>
h = <optimized out>
#4 0x0000000000564649 in xsignal (error_symbol=error_symbol@entry=28656, data=<optimized out>) at eval.c:1577
No locals.
#5 0x0000000000565157 in xsignal1 (error_symbol=error_symbol@entry=28656, arg=<optimized out>) at eval.c:1592
No locals.
#6 0x0000000000533fee in compile_pattern_1 (posix=<optimized out>, translate=0, pattern=<optimized out>, cp=0xb935d0 <searchbufs+6480>) at search.c:154
val = 0x600576 "Regular expression too big"
old = 0
#7 compile_pattern (pattern=pattern@entry=61362260, regp=regp@entry=0x0, translate=translate@entry=0, posix=posix@entry=false, multibyte=<optimized out>) at search.c:237
cp = 0xb935d0 <searchbufs+6480>
cpp = <optimized out>
#8 0x000000000053619d in fast_string_match_internal (regexp=regexp@entry=61362260, string=string@entry=61914372, table=table@entry=0) at search.c:471
val = 0
bufp = <optimized out>
#9 0x000000000051dd61 in fast_string_match (string=61914372, regexp=61362260) at lisp.h:4010
No locals.
#10 Ffind_file_name_handler (filename=filename@entry=61914372, operation=operation@entry=19872) at fileio.c:292
operations = 0
chain = 61546355
inhibited_handlers = 0
result = 0
pos = -1
#11 0x000000000051f3c0 in Fexpand_file_name (name=61914372, default_directory=default_directory@entry=0) at fileio.c:809
nm = <optimized out>
nmlim = <optimized out>
newdir = <optimized out>
newdirlim = <optimized out>
target = <optimized out>
tlen = <optimized out>
pw = <optimized out>
length = <optimized out>
nbytes = <optimized out>
handler = <optimized out>
result = <optimized out>
handled_name = <optimized out>
multibyte = <optimized out>
hdir = <optimized out>
sa_avail = 16384
sa_must_free = false
#12 0x0000000000524298 in Fdo_auto_save (no_message=<optimized out>, no_message@entry=44448, current_only=current_only@entry=0) at fileio.c:5521
listfile = <optimized out>
old = 0x37e8330
tail = <optimized out>
auto_saved = false
do_handled_files = <optimized out>
oquit = 0
stream = 0x0
orig_minibuffer_auto_raise = false
old_message_p = false
auto_save_unwind = {stream = 0x7f647864bf6e, auto_raise = 40}
#13 0x00000000004effa0 in shut_down_emacs (sig=sig@entry=11, stuff=stuff@entry=0) at emacs.c:2000
No locals.
#14 0x00000000004f0155 in terminate_due_to_signal (sig=sig@entry=11, backtrace_limit=backtrace_limit@entry=40) at emacs.c:365
No locals.
#15 0x0000000000507c7e in handle_fatal_signal (sig=sig@entry=11) at sysdep.c:1601
No locals.
#16 0x0000000000507e33 in deliver_thread_signal (sig=sig@entry=11, handler=0x507c70 <handle_fatal_signal>) at sysdep.c:1575
No locals.
#17 0x0000000000507ebc in deliver_fatal_thread_signal (sig=11) at sysdep.c:1613
No locals.
#18 handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>) at sysdep.c:1695
fatal = <optimized out>
#19 <signal handler called>
No locals.
#20 mark_object (arg=<optimized out>) at alloc.c:6446
ptr = 0x5ea9170
obj = <optimized out>
po = <optimized out>
cdr_count = <optimized out>
#21 0x000000000054bb63 in mark_object (arg=<optimized out>) at alloc.c:6539
obj = <optimized out>
po = <optimized out>
cdr_count = 2174
#22 0x000000000054d28e in mark_maybe_pointer (p=0x52eb480) at alloc.c:4845
obj = <optimized out>
m = <optimized out>
#23 mark_memory (end=0x7fff02b540a8, start=<optimized out>) at alloc.c:4894
pp = 0x7fff02b514e8 "\200\264.\005"
#24 mark_stack (end=0x7fff02b4f898) at alloc.c:5038
No locals.
#25 garbage_collect_1 (end=0x7fff02b4f898) at alloc.c:5756
nextb = <optimized out>
i = <optimized out>
retval = <optimized out>
stack_top_variable = 0 '\000'
message_p = false
tot_before = 0
total = {58591408, 0, 0, 8, 2, 5652410, 374496, 11808, 0, -6202091921070732288, 8}
#26 Fgarbage_collect () at alloc.c:5979
end = 0x7fff02b4f898
#27 0x00000000005639cc in maybe_gc () at lisp.h:4656
No locals.
#28 Ffuncall (nargs=86946816, args=0x7fff02b4fa68) at eval.c:2643
numargs = 1
val = 333
internal_args = 0x7fff02b4fa70
count = 17
#29 0x00000000005988f3 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=args_template@entry=0, nargs=nargs@entry=0,
args=<optimized out>, args@entry=0x0) at bytecode.c:880
targets = {0x598a78 <exec_byte_code+888>, 0x59a050 <exec_byte_code+6480>, 0x59a058 <exec_byte_code+6488>, 0x59a060 <exec_byte_code+6496>, 0x598838 <exec_byte_code+312>,
0x598840 <exec_byte_code+320>, 0x599be0 <exec_byte_code+5344>, 0x599c30 <exec_byte_code+5424>, 0x59a068 <exec_byte_code+6504>, 0x598b08 <exec_byte_code+1032>,
0x598ac0 <exec_byte_code+960>, 0x598b10 <exec_byte_code+1040>, 0x598a08 <exec_byte_code+776>, 0x598a10 <exec_byte_code+784>, 0x59a110 <exec_byte_code+6672>,
0x598ac8 <exec_byte_code+968>, 0x598b18 <exec_byte_code+1048>, 0x599ec0 <exec_byte_code+6080>, 0x59a320 <exec_byte_code+7200>, 0x599f08 <exec_byte_code+6152>,
0x598990 <exec_byte_code+656>, 0x598990 <exec_byte_code+656>, 0x59a2d8 <exec_byte_code+7128>, 0x599ec8 <exec_byte_code+6088>, 0x599f38 <exec_byte_code+6200>,
0x599f40 <exec_byte_code+6208>, 0x599f90 <exec_byte_code+6288>, 0x598b20 <exec_byte_code+1056>, 0x598880 <exec_byte_code+384>, 0x598880 <exec_byte_code+384>,
0x599ef0 <exec_byte_code+6128>, 0x599f10 <exec_byte_code+6160>, 0x599f88 <exec_byte_code+6280>, 0x599f98 <exec_byte_code+6296>, 0x599fa0 <exec_byte_code+6304>,
0x598b28 <exec_byte_code+1064>, 0x5988c8 <exec_byte_code+456>, 0x5988d0 <exec_byte_code+464>, 0x599f48 <exec_byte_code+6216>, 0x599f60 <exec_byte_code+6240>,
0x599fd8 <exec_byte_code+6360>, 0x599fd0 <exec_byte_code+6352>, 0x599fe0 <exec_byte_code+6368>, 0x598b30 <exec_byte_code+1072>, 0x598918 <exec_byte_code+536>,
0x598920 <exec_byte_code+544>, 0x598af0 <exec_byte_code+1008>, 0x599fa8 <exec_byte_code+6312>, 0x599ad0 <exec_byte_code+5072>, 0x5999f0 <exec_byte_code+4848>,
0x59a040 <exec_byte_code+6464>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>,
0x598a78 <exec_byte_code+888>, 0x5990b0 <exec_byte_code+2480>, 0x599140 <exec_byte_code+2624>, 0x599188 <exec_byte_code+2696>, 0x5991d0 <exec_byte_code+2768>,
0x599220 <exec_byte_code+2848>, 0x59a290 <exec_byte_code+7056>, 0x59a1d0 <exec_byte_code+6864>, 0x599268 <exec_byte_code+2920>, 0x59a250 <exec_byte_code+6992>,
0x59a210 <exec_byte_code+6928>, 0x5992a0 <exec_byte_code+2976>, 0x5992e0 <exec_byte_code+3040>, 0x599310 <exec_byte_code+3088>, 0x599350 <exec_byte_code+3152>,
0x599388 <exec_byte_code+3208>, 0x599410 <exec_byte_code+3344>, 0x599440 <exec_byte_code+3392>, 0x599480 <exec_byte_code+3456>, 0x5994c0 <exec_byte_code+3520>,
0x5994f0 <exec_byte_code+3568>, 0x599520 <exec_byte_code+3616>, 0x599560 <exec_byte_code+3680>, 0x5995a0 <exec_byte_code+3744>, 0x5995e0 <exec_byte_code+3808>,
0x599620 <exec_byte_code+3872>, 0x599658 <exec_byte_code+3928>, 0x599690 <exec_byte_code+3984>, 0x599718 <exec_byte_code+4120>, 0x599760 <exec_byte_code+4192>,
0x5997a8 <exec_byte_code+4264>, 0x599880 <exec_byte_code+4480>, 0x5997f8 <exec_byte_code+4344>, 0x599840 <exec_byte_code+4416>, 0x5998c0 <exec_byte_code+4544>,
0x599900 <exec_byte_code+4608>, 0x599938 <exec_byte_code+4664>, 0x599980 <exec_byte_code+4736>, 0x59a960 <exec_byte_code+8800>, 0x59a998 <exec_byte_code+8856>,
0x59a9d0 <exec_byte_code+8912>, 0x59a7c0 <exec_byte_code+8384>, 0x598960 <exec_byte_code+608>, 0x59a800 <exec_byte_code+8448>, 0x59a830 <exec_byte_code+8496>,
0x59a8b0 <exec_byte_code+8624>, 0x59a8f0 <exec_byte_code+8688>, 0x59a930 <exec_byte_code+8752>, 0x59a440 <exec_byte_code+7488>, 0x59a470 <exec_byte_code+7536>,
0x59a4a0 <exec_byte_code+7584>, 0x59a4d8 <exec_byte_code+7640>, 0x598a78 <exec_byte_code+888>, 0x59a508 <exec_byte_code+7688>, 0x59a538 <exec_byte_code+7736>,
0x59a568 <exec_byte_code+7784>, 0x59a598 <exec_byte_code+7832>, 0x59a5c8 <exec_byte_code+7880>, 0x59a5f8 <exec_byte_code+7928>, 0x598960 <exec_byte_code+608>,
0x598a78 <exec_byte_code+888>, 0x59a628 <exec_byte_code+7976>, 0x59a670 <exec_byte_code+8048>, 0x59a6a0 <exec_byte_code+8096>, 0x59a6d0 <exec_byte_code+8144>,
0x59a710 <exec_byte_code+8208>, 0x59a750 <exec_byte_code+8272>, 0x599e58 <exec_byte_code+5976>, 0x599e80 <exec_byte_code+6016>, 0x59af40 <exec_byte_code+10304>,
0x59af80 <exec_byte_code+10368>, 0x59ae70 <exec_byte_code+10096>, 0x59aea0 <exec_byte_code+10144>, 0x598a78 <exec_byte_code+888>, 0x59a3e8 <exec_byte_code+7400>,
0x598b60 <exec_byte_code+1120>, 0x59a128 <exec_byte_code+6696>, 0x598c10 <exec_byte_code+1296>, 0x598cc0 <exec_byte_code+1472>, 0x598d68 <exec_byte_code+1640>,
0x599fe8 <exec_byte_code+6376>, 0x59a3c0 <exec_byte_code+7360>, 0x59a2f0 <exec_byte_code+7152>, 0x59a328 <exec_byte_code+7208>, 0x59a360 <exec_byte_code+7264>,
0x5999b8 <exec_byte_code+4792>, 0x599a88 <exec_byte_code+5000>, 0x599b00 <exec_byte_code+5120>, 0x599b50 <exec_byte_code+5200>, 0x599b90 <exec_byte_code+5264>,
0x599050 <exec_byte_code+2384>, 0x598b38 <exec_byte_code+1080>, 0x59aed0 <exec_byte_code+10192>, 0x59af10 <exec_byte_code+10256>, 0x59ac28 <exec_byte_code+9512>,
0x59ac58 <exec_byte_code+9560>, 0x59ac88 <exec_byte_code+9608>, 0x59acb8 <exec_byte_code+9656>, 0x59acf8 <exec_byte_code+9720>, 0x59ad38 <exec_byte_code+9784>,
0x59ad78 <exec_byte_code+9848>, 0x59adb8 <exec_byte_code+9912>, 0x59aa40 <exec_byte_code+9024>, 0x59aa80 <exec_byte_code+9088>, 0x59aac0 <exec_byte_code+9152>,
0x59aaf0 <exec_byte_code+9200>, 0x59ab30 <exec_byte_code+9264>, 0x59ab70 <exec_byte_code+9328>, 0x59abb0 <exec_byte_code+9392>, 0x59abf0 <exec_byte_code+9456>,
0x59aa08 <exec_byte_code+8968>, 0x59a780 <exec_byte_code+8320>, 0x59a070 <exec_byte_code+6512>, 0x59a0c0 <exec_byte_code+6592>, 0x598a78 <exec_byte_code+888>,
0x598e10 <exec_byte_code+1808>, 0x598ea0 <exec_byte_code+1952>, 0x598f30 <exec_byte_code+2096>, 0x598fc0 <exec_byte_code+2240>, 0x599dc8 <exec_byte_code+5832>,
0x5993c0 <exec_byte_code+3264>, 0x5996c8 <exec_byte_code+4040>, 0x59a860 <exec_byte_code+8544>, 0x599c90 <exec_byte_code+5520>, 0x599ce0 <exec_byte_code+5600>,
0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x599d40 <exec_byte_code+5696>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>,
0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>,
0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x599d90 <exec_byte_code+5776> <repeats 64 times>}
count = 10
op = <optimized out>
vectorp = 0x1443438
stack = {pc = 0x3631990 "\210\320\321!).\006\207", byte_string = 21113700, byte_string_start = 0x3631960 "\b\205\067", next = 0x0}
top = 0x7fff02b4fa68
result = <optimized out>
type = <optimized out>
#30 0x0000000000563732 in funcall_lambda (fun=57191557, nargs=2, arg_vector=0x7fff02b4fcc8) at eval.c:2921
val = <optimized out>
syms_left = 0
lexenv = 0
i = <optimized out>
optional = <optimized out>
rest = <optimized out>
#31 0x0000000000563b13 in Ffuncall (nargs=86946816, args=0x368ac80) at eval.c:2754
numargs = 2
val = 333
internal_args = 0x7fff02b4fcc8
count = 7
#32 0x0000000000564059 in funcall_nil (nargs=<optimized out>, args=<optimized out>) at eval.c:2332
No locals.
#33 0x000000000056205d in run_hook_with_args (nargs=3, args=0x7fff02b4fcc0, funcall=0x564050 <funcall_nil>) at eval.c:2509
global_vals = <optimized out>
sym = 50784
val = 61477811
ret = 0
#34 0x000000000056282e in run_hook_with_args (funcall=<optimized out>, args=<optimized out>, nargs=<optimized out>) at eval.c:2459
No locals.
#35 Frun_hook_with_args (args=0x7fff02b4fcc0, nargs=3) at eval.c:2374
args = 0x7fff02b4fcc0
nargs = 3
#36 run_hook_with_args_2 (hook=hook@entry=50784, arg1=arg1@entry=58591413, arg2=arg2@entry=1553398) at eval.c:2530
No locals.
#37 0x0000000000432465 in run_window_scroll_functions (window=58591413, startp=...) at xdisp.c:15110
No locals.
#38 0x000000000046443a in redisplay_window (window=58591413, just_this_one_p=false, just_this_one_p@entry=true) at xdisp.c:16382
new_vpos = 391173
startp = {charpos = 333, bytepos = 334}
it = {window = 58591413, w = 0x37e08b0, f = 0x1224650, method = GET_FROM_BUFFER, stop_charpos = 391173, prev_stop = 391082, base_level_stop = 391082, end_charpos = 391173, s = 0x0,
string_nchars = 0, redisplay_end_trigger_charpos = 0, multibyte_p = true, header_line_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false,
from_disp_prop_p = false, ellipsis_p = false, avoid_cursor_p = false, dp = 0x0, dpvec = 0x0, dpend = 0x0, dpvec_char_len = 0, dpvec_face_id = 0, saved_face_id = 0, ctl_chars = {
0 <repeats 16 times>}, start = {pos = {charpos = 388349, bytepos = 388357}, overlay_string_index = -1, string_pos = {charpos = -1, bytepos = -1}, dpvec_index = -1}, current = {
pos = {charpos = 391173, bytepos = 391181}, overlay_string_index = -1, string_pos = {charpos = -1, bytepos = -1}, dpvec_index = -1}, n_overlay_strings = 0,
overlay_strings_charpos = 391173, overlay_strings = {0 <repeats 16 times>}, string_overlays = {0 <repeats 16 times>}, string = 0, from_overlay = 0, stack = {{string = 0,
string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = {stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0,
reversed_p = false, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0}, face_id = 0, u = {image = {object = 0, slice = {x = 0, y = 0, width = 0, height = 0},
image_id = 0}, stretch = {object = 0}, xwidget = {object = 0}}, position = {charpos = 0, bytepos = 0}, current = {pos = {charpos = 0, bytepos = 0}, overlay_string_index = 0,
string_pos = {charpos = 0, bytepos = 0}, dpvec_index = 0}, from_overlay = 0, area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR,
multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false,
from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = 0, font_height = 0}, {string = 0, string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0,
base_level_stop = 0, cmp_it = {stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0,
width = 0}, face_id = 0, u = {image = {object = 0, slice = {x = 0, y = 0, width = 0, height = 0}, image_id = 0}, stretch = {object = 0}, xwidget = {object = 0}}, position = {
charpos = 0, bytepos = 0}, current = {pos = {charpos = 0, bytepos = 0}, overlay_string_index = 0, string_pos = {charpos = 0, bytepos = 0}, dpvec_index = 0}, from_overlay = 0,
area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false,
display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = 0, font_height = 0}, {string = 0,
string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = {stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0,
reversed_p = false, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0}, face_id = 0, u = {image = {object = 0, slice = {x = 0, y = 0, width = 0, height = 0},
image_id = 0}, stretch = {object = 0}, xwidget = {object = 0}}, position = {charpos = 0, bytepos = 0}, current = {pos = {charpos = 0, bytepos = 0}, overlay_string_index = 0,
string_pos = {charpos = 0, bytepos = 0}, dpvec_index = 0}, from_overlay = 0, area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR,
multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false,
from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = 0, font_height = 0}, {string = 0, string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0,
base_level_stop = 0, cmp_it = {stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0,
width = 0}, face_id = 0, u = {image = {object = 0, slice = {x = 0, y = 0, width = 0, height = 0}, image_id = 0}, stretch = {object = 0}, xwidget = {object = 0}}, position = {
charpos = 0, bytepos = 0}, current = {pos = {charpos = 0, bytepos = 0}, overlay_string_index = 0, string_pos = {charpos = 0, bytepos = 0}, dpvec_index = 0}, from_overlay = 0,
area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false,
display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = 0, font_height = 0}, {string = 0,
string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = {stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0,
reversed_p = false, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0}, face_id = 0, u = {image = {object = 0, slice = {x = 0, y = 0, width = 0, height = 0},
image_id = 0}, stretch = {object = 0}, xwidget = {object = 0}}, position = {charpos = 0, bytepos = 0}, current = {pos = {charpos = 0, bytepos = 0}, overlay_string_index = 0,
string_pos = {charpos = 0, bytepos = 0}, dpvec_index = 0}, from_overlay = 0, area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR,
multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false,
from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = 0, font_height = 0}}, sp = 0, selective = 0, what = IT_EOB, face_id = 0,
selective_display_ellipsis_p = true, ctl_arrow_p = true, face_box_p = false, start_of_box_run_p = false, end_of_box_run_p = false, overlay_strings_at_end_processed_p = true,
ignore_overlay_strings_at_pos_p = false, glyph_not_available_p = false, starts_in_middle_of_char_p = false, face_before_selective_p = false, constrain_row_ascent_descent_p = false,
line_wrap = WINDOW_WRAP, base_face_id = 0, c = 32, len = 1, cmp_it = {stop_pos = 391171, id = -1, ch = -2, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, charpos = 0,
nchars = 0, nbytes = 0, from = 0, to = 0, width = 0}, char_to_display = 32, glyphless_method = GLYPHLESS_DISPLAY_THIN_SPACE, image_id = 0, xwidget = 0x0, slice = {x = 0, y = 0,
width = 0, height = 0}, space_width = 0, voffset = 0, tab_width = 4, font_height = 0, object = 58622773, position = {charpos = 391173, bytepos = 391181}, truncation_pixel_width = 0,
continuation_pixel_width = 6, first_visible_x = 0, last_visible_x = 480, last_visible_y = 663, extra_line_spacing = 1, max_extra_line_spacing = 1, override_ascent = -1,
override_descent = 0, override_boff = 0, glyph_row = 0x3b39c30, area = TEXT_AREA, nglyphs = 1, pixel_width = 6, ascent = 11, descent = 3, max_ascent = 11, max_descent = 3,
phys_ascent = 0, phys_descent = 0, max_phys_ascent = 11, max_phys_descent = 2, current_x = 12, continuation_lines_width = 0, eol_pos = {charpos = 0, bytepos = 0}, current_y = 644,
first_vpos = 0, vpos = 46, hpos = 2, left_user_fringe_bitmap = 0, right_user_fringe_bitmap = 0, left_user_fringe_face_id = 0, right_user_fringe_face_id = 0, bidi_p = true, bidi_it = {
bytepos = 391181, charpos = 391173, ch = -1, nchars = 1, ch_len = 1, type = NEUTRAL_B, type_after_wn = NEUTRAL_B, orig_type = NEUTRAL_B, resolved_level = 0 '\000',
isolate_level = 0 '\000', invalid_levels = 0, invalid_isolates = 0, prev = {charpos = 391172, type = UNKNOWN_BT, orig_type = NEUTRAL_WS}, last_strong = {charpos = 391168,
type = UNKNOWN_BT, orig_type = UNKNOWN_BT}, next_for_neutral = {charpos = 390500, type = UNKNOWN_BT, orig_type = UNKNOWN_BT}, prev_for_neutral = {charpos = 391173,
type = STRONG_L, orig_type = NEUTRAL_WS}, next_for_ws = {charpos = -1, type = UNKNOWN_BT, orig_type = UNKNOWN_BT}, bracket_pairing_pos = -1, bracket_enclosed_type = UNKNOWN_BT,
next_en_pos = 0, next_en_type = UNKNOWN_BT, sos = L2R, scan_dir = 1, disp_pos = 391173, disp_prop = 0, stack_idx = 0, level_stack = {{next_for_neutral_pos = 0,
next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000'} <repeats 128 times>}, string = {lstring = 0, s = 0x0, schars = 0,
bufpos = 0, from_disp_str = false, unibyte = false}, w = 0x37e08b0, paragraph_dir = L2R, separator_limit = -1, first_elt = false, new_paragraph = false, frame_window_p = true},
paragraph_embedding = NEUTRAL_DIR}
temp_scroll_step = true
rc = 0
last_line_misfit = false
itdata = 0x7fff02b4fe10
#39 0x0000000000467a1e in redisplay_window_1 (window=window@entry=58591413) at xdisp.c:14454
No locals.
#40 0x000000000056260c in internal_condition_case_1 (bfun=0x4679f0 <redisplay_window_1>, arg=58591413, handlers=<optimized out>, hfun=0x42cf60 <redisplay_window_error>) at eval.c:1333
val = 333
c = <optimized out>
#41 0x0000000000456ad0 in redisplay_internal () at xdisp.c:14079
match_p = 176
#42 0x00000000004fa2b3 in read_char (commandflag=86946816, commandflag@entry=1, map=86617088, map@entry=86601331, prev_event=334, used_mouse_menu=0x0, used_mouse_menu@entry=0x7fff02b53dcb,
end_time=0x143ba01, end_time@entry=0x0) at keyboard.c:2477
local_getcjmp = {{__jmpbuf = {58622773, 1564694, 29472, 1564690, 391168, 5988911, 391172, 66918760228998144}, __mask_was_saved = 45431872, __saved_mask = {__val = {1564694,
140733238819904, 29472, 391181, 18446744073709551615, 58622773, 5597497, 3, 401584, 58622768, 3743, 12620597, 391173, 1564694, 58622773, 0}}}}
save_jump = {{__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = {__val = {0 <repeats 16 times>}}}}
save = 13951632
previous_echo_area_message = 0
also_record = 0
reread = false
recorded = false
polling_stopped_here = false
#43 0x00000000004fca76 in read_key_sequence (keybuf=keybuf@entry=0x7fff02b53ea0, prompt=prompt@entry=0, dont_downcase_last=dont_downcase_last@entry=false,
can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false, bufsize=30) at keyboard.c:9063
interrupted_kboard = 0xd4e290
interrupted_frame = 0x1224650
key = <optimized out>
used_mouse_menu = false
echo_local_start = 0
last_real_key_start = <optimized out>
keys_local_start = <optimized out>
new_binding = <optimized out>
t = <optimized out>
echo_start = 0
keys_start = 0
current_binding = 86601331
first_event = 0
first_unbound = 31
mock_input = 0
fkey = {parent = 17130995, map = 17130995, start = 0, end = 0}
keytran = {parent = 12570179, map = 12570179, start = 0, end = 0}
indec = {parent = 17131123, map = 17131123, start = 0, end = 0}
shift_translated = false
delayed_switch_frame = 0
original_uppercase = 0
original_uppercase_position = -1
dummyflag = false
starting_buffer = 0x37e8330
fake_prefixed_keys = 0
#44 0x00000000004fe6b6 in command_loop_1 () at keyboard.c:1365
cmd = <optimized out>
keybuf = {54, 78, 202, -6202091921070732288, 2822930839, -6202091921070732288, 9955464, 5377136, 73708083, 140733238820720, 73708083, 140733238821408, 0, 5652260, 317296, 73708083,
8756772, 5377136, 12340336, -6202091921070732288, 73708083, 5197970, 140733238820720, 0, 0, 5198303, 140733238821376, 5579137, 28416, 96}
i = <optimized out>
prev_modiff = 46990
prev_buffer = 0x37e8330
#45 0x0000000000562686 in internal_condition_case (bfun=bfun@entry=0x4fe4b0 <command_loop_1>, handlers=handlers@entry=19056, hfun=hfun@entry=0x4f50c0 <cmd_error>) at eval.c:1309
val = 333
c = <optimized out>
#46 0x00000000004f06ec in command_loop_2 (ignore=ignore@entry=0) at keyboard.c:1107
val = 333
#47 0x00000000005626eb in internal_catch (tag=tag@entry=45840, func=func@entry=0x4f06d0 <command_loop_2>, arg=arg@entry=0) at eval.c:1074
val = 333
c = <optimized out>
#48 0x00000000004f06a9 in command_loop () at keyboard.c:1086
No locals.
#49 0x00000000004f4cd7 in recursive_edit_1 () at keyboard.c:692
val = <optimized out>
#50 0x00000000004f4ff0 in Frecursive_edit () at keyboard.c:763
buffer = <optimized out>
#51 0x0000000000418dce in main (argc=1, argv=0x7fff02b54228) at emacs.c:1626
dummy = 140069625578752
stack_bottom_variable = 2 '\002'
skip_args = 0
rlim = {rlim_cur = 8720000, rlim_max = 18446744073709551615}
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
#0 0x00007f6478ab875b in raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
resultvar = 0
pid = <optimized out>
#1 0x00000000004f0184 in terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40) at emacs.c:381
No locals.
#2 0x0000000000508fd3 in emacs_abort () at sysdep.c:2247
No locals.
#3 0x000000000056463b in Fsignal (error_symbol=error_symbol@entry=28656, data=86599795) at eval.c:1478
conditions = <optimized out>
string = <optimized out>
real_error_symbol = 28656
clause = <optimized out>
h = <optimized out>
#4 0x0000000000564649 in xsignal (error_symbol=error_symbol@entry=28656, data=<optimized out>) at eval.c:1577
No locals.
#5 0x0000000000565157 in xsignal1 (error_symbol=error_symbol@entry=28656, arg=<optimized out>) at eval.c:1592
No locals.
#6 0x0000000000533fee in compile_pattern_1 (posix=<optimized out>, translate=0, pattern=<optimized out>, cp=0xb935d0 <searchbufs+6480>) at search.c:154
val = 0x600576 "Regular expression too big"
old = 0
#7 compile_pattern (pattern=pattern@entry=61362260, regp=regp@entry=0x0, translate=translate@entry=0, posix=posix@entry=false, multibyte=<optimized out>) at search.c:237
cp = 0xb935d0 <searchbufs+6480>
cpp = <optimized out>
#8 0x000000000053619d in fast_string_match_internal (regexp=regexp@entry=61362260, string=string@entry=61914372, table=table@entry=0) at search.c:471
val = 0
bufp = <optimized out>
#9 0x000000000051dd61 in fast_string_match (string=61914372, regexp=61362260) at lisp.h:4010
No locals.
#10 Ffind_file_name_handler (filename=filename@entry=61914372, operation=operation@entry=19872) at fileio.c:292
operations = 0
chain = 61546355
inhibited_handlers = 0
result = 0
pos = -1
#11 0x000000000051f3c0 in Fexpand_file_name (name=61914372, default_directory=default_directory@entry=0) at fileio.c:809
nm = <optimized out>
nmlim = <optimized out>
newdir = <optimized out>
newdirlim = <optimized out>
target = <optimized out>
tlen = <optimized out>
pw = <optimized out>
length = <optimized out>
nbytes = <optimized out>
handler = <optimized out>
result = <optimized out>
handled_name = <optimized out>
multibyte = <optimized out>
hdir = <optimized out>
sa_avail = 16384
sa_must_free = false
#12 0x0000000000524298 in Fdo_auto_save (no_message=<optimized out>, no_message@entry=44448, current_only=current_only@entry=0) at fileio.c:5521
listfile = <optimized out>
old = 0x37e8330
tail = <optimized out>
auto_saved = false
do_handled_files = <optimized out>
oquit = 0
stream = 0x0
orig_minibuffer_auto_raise = false
old_message_p = false
auto_save_unwind = {
stream = 0x7f647864bf6e,
auto_raise = 40
}
#13 0x00000000004effa0 in shut_down_emacs (sig=sig@entry=11, stuff=stuff@entry=0) at emacs.c:2000
No locals.
#14 0x00000000004f0155 in terminate_due_to_signal (sig=sig@entry=11, backtrace_limit=backtrace_limit@entry=40) at emacs.c:365
No locals.
#15 0x0000000000507c7e in handle_fatal_signal (sig=sig@entry=11) at sysdep.c:1601
No locals.
#16 0x0000000000507e33 in deliver_thread_signal (sig=sig@entry=11, handler=0x507c70 <handle_fatal_signal>) at sysdep.c:1575
No locals.
#17 0x0000000000507ebc in deliver_fatal_thread_signal (sig=11) at sysdep.c:1613
No locals.
#18 handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>) at sysdep.c:1695
fatal = <optimized out>
#19 <signal handler called>
No locals.
#20 mark_object (arg=<optimized out>) at alloc.c:6446
ptr = 0x5ea9170
obj = <optimized out>
po = <optimized out>
cdr_count = <optimized out>
#21 0x000000000054bb63 in mark_object (arg=<optimized out>) at alloc.c:6539
obj = <optimized out>
po = <optimized out>
cdr_count = 2174
#22 0x000000000054d28e in mark_maybe_pointer (p=0x52eb480) at alloc.c:4845
obj = <optimized out>
m = <optimized out>
#23 mark_memory (end=0x7fff02b540a8, start=<optimized out>) at alloc.c:4894
pp = 0x7fff02b514e8 "\200\264.\005"
#24 mark_stack (end=0x7fff02b4f898) at alloc.c:5038
No locals.
#25 garbage_collect_1 (end=0x7fff02b4f898) at alloc.c:5756
nextb = <optimized out>
i = <optimized out>
retval = <optimized out>
stack_top_variable = 0 '\000'
message_p = false
tot_before = 0
total = {58591408, 0, 0, 8, 2, 5652410, 374496, 11808, 0, -6202091921070732288, 8}
#26 Fgarbage_collect () at alloc.c:5979
end = 0x7fff02b4f898
#27 0x00000000005639cc in maybe_gc () at lisp.h:4656
No locals.
#28 Ffuncall (nargs=86946816, args=0x7fff02b4fa68) at eval.c:2643
numargs = 1
val = 333
internal_args = 0x7fff02b4fa70
count = 17
#29 0x00000000005988f3 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=args_template@entry=0, nargs=nargs@entry=0,
args=<optimized out>, args@entry=0x0) at bytecode.c:880
targets = {0x598a78 <exec_byte_code+888>, 0x59a050 <exec_byte_code+6480>, 0x59a058 <exec_byte_code+6488>, 0x59a060 <exec_byte_code+6496>, 0x598838 <exec_byte_code+312>,
0x598840 <exec_byte_code+320>, 0x599be0 <exec_byte_code+5344>, 0x599c30 <exec_byte_code+5424>, 0x59a068 <exec_byte_code+6504>, 0x598b08 <exec_byte_code+1032>,
0x598ac0 <exec_byte_code+960>, 0x598b10 <exec_byte_code+1040>, 0x598a08 <exec_byte_code+776>, 0x598a10 <exec_byte_code+784>, 0x59a110 <exec_byte_code+6672>,
0x598ac8 <exec_byte_code+968>, 0x598b18 <exec_byte_code+1048>, 0x599ec0 <exec_byte_code+6080>, 0x59a320 <exec_byte_code+7200>, 0x599f08 <exec_byte_code+6152>,
0x598990 <exec_byte_code+656>, 0x598990 <exec_byte_code+656>, 0x59a2d8 <exec_byte_code+7128>, 0x599ec8 <exec_byte_code+6088>, 0x599f38 <exec_byte_code+6200>,
0x599f40 <exec_byte_code+6208>, 0x599f90 <exec_byte_code+6288>, 0x598b20 <exec_byte_code+1056>, 0x598880 <exec_byte_code+384>, 0x598880 <exec_byte_code+384>,
0x599ef0 <exec_byte_code+6128>, 0x599f10 <exec_byte_code+6160>, 0x599f88 <exec_byte_code+6280>, 0x599f98 <exec_byte_code+6296>, 0x599fa0 <exec_byte_code+6304>,
0x598b28 <exec_byte_code+1064>, 0x5988c8 <exec_byte_code+456>, 0x5988d0 <exec_byte_code+464>, 0x599f48 <exec_byte_code+6216>, 0x599f60 <exec_byte_code+6240>,
0x599fd8 <exec_byte_code+6360>, 0x599fd0 <exec_byte_code+6352>, 0x599fe0 <exec_byte_code+6368>, 0x598b30 <exec_byte_code+1072>, 0x598918 <exec_byte_code+536>,
0x598920 <exec_byte_code+544>, 0x598af0 <exec_byte_code+1008>, 0x599fa8 <exec_byte_code+6312>, 0x599ad0 <exec_byte_code+5072>, 0x5999f0 <exec_byte_code+4848>,
0x59a040 <exec_byte_code+6464>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>,
0x598a78 <exec_byte_code+888>, 0x5990b0 <exec_byte_code+2480>, 0x599140 <exec_byte_code+2624>, 0x599188 <exec_byte_code+2696>, 0x5991d0 <exec_byte_code+2768>,
0x599220 <exec_byte_code+2848>, 0x59a290 <exec_byte_code+7056>, 0x59a1d0 <exec_byte_code+6864>, 0x599268 <exec_byte_code+2920>, 0x59a250 <exec_byte_code+6992>,
0x59a210 <exec_byte_code+6928>, 0x5992a0 <exec_byte_code+2976>, 0x5992e0 <exec_byte_code+3040>, 0x599310 <exec_byte_code+3088>, 0x599350 <exec_byte_code+3152>,
0x599388 <exec_byte_code+3208>, 0x599410 <exec_byte_code+3344>, 0x599440 <exec_byte_code+3392>, 0x599480 <exec_byte_code+3456>, 0x5994c0 <exec_byte_code+3520>,
0x5994f0 <exec_byte_code+3568>, 0x599520 <exec_byte_code+3616>, 0x599560 <exec_byte_code+3680>, 0x5995a0 <exec_byte_code+3744>, 0x5995e0 <exec_byte_code+3808>,
0x599620 <exec_byte_code+3872>, 0x599658 <exec_byte_code+3928>, 0x599690 <exec_byte_code+3984>, 0x599718 <exec_byte_code+4120>, 0x599760 <exec_byte_code+4192>,
0x5997a8 <exec_byte_code+4264>, 0x599880 <exec_byte_code+4480>, 0x5997f8 <exec_byte_code+4344>, 0x599840 <exec_byte_code+4416>, 0x5998c0 <exec_byte_code+4544>,
0x599900 <exec_byte_code+4608>, 0x599938 <exec_byte_code+4664>, 0x599980 <exec_byte_code+4736>, 0x59a960 <exec_byte_code+8800>, 0x59a998 <exec_byte_code+8856>,
0x59a9d0 <exec_byte_code+8912>, 0x59a7c0 <exec_byte_code+8384>, 0x598960 <exec_byte_code+608>, 0x59a800 <exec_byte_code+8448>, 0x59a830 <exec_byte_code+8496>,
0x59a8b0 <exec_byte_code+8624>, 0x59a8f0 <exec_byte_code+8688>, 0x59a930 <exec_byte_code+8752>, 0x59a440 <exec_byte_code+7488>, 0x59a470 <exec_byte_code+7536>,
0x59a4a0 <exec_byte_code+7584>, 0x59a4d8 <exec_byte_code+7640>, 0x598a78 <exec_byte_code+888>, 0x59a508 <exec_byte_code+7688>, 0x59a538 <exec_byte_code+7736>,
0x59a568 <exec_byte_code+7784>, 0x59a598 <exec_byte_code+7832>, 0x59a5c8 <exec_byte_code+7880>, 0x59a5f8 <exec_byte_code+7928>, 0x598960 <exec_byte_code+608>,
0x598a78 <exec_byte_code+888>, 0x59a628 <exec_byte_code+7976>, 0x59a670 <exec_byte_code+8048>, 0x59a6a0 <exec_byte_code+8096>, 0x59a6d0 <exec_byte_code+8144>,
0x59a710 <exec_byte_code+8208>, 0x59a750 <exec_byte_code+8272>, 0x599e58 <exec_byte_code+5976>, 0x599e80 <exec_byte_code+6016>, 0x59af40 <exec_byte_code+10304>,
0x59af80 <exec_byte_code+10368>, 0x59ae70 <exec_byte_code+10096>, 0x59aea0 <exec_byte_code+10144>, 0x598a78 <exec_byte_code+888>, 0x59a3e8 <exec_byte_code+7400>,
0x598b60 <exec_byte_code+1120>, 0x59a128 <exec_byte_code+6696>, 0x598c10 <exec_byte_code+1296>, 0x598cc0 <exec_byte_code+1472>, 0x598d68 <exec_byte_code+1640>,
0x599fe8 <exec_byte_code+6376>, 0x59a3c0 <exec_byte_code+7360>, 0x59a2f0 <exec_byte_code+7152>, 0x59a328 <exec_byte_code+7208>, 0x59a360 <exec_byte_code+7264>,
0x5999b8 <exec_byte_code+4792>, 0x599a88 <exec_byte_code+5000>, 0x599b00 <exec_byte_code+5120>, 0x599b50 <exec_byte_code+5200>, 0x599b90 <exec_byte_code+5264>,
0x599050 <exec_byte_code+2384>, 0x598b38 <exec_byte_code+1080>, 0x59aed0 <exec_byte_code+10192>, 0x59af10 <exec_byte_code+10256>, 0x59ac28 <exec_byte_code+9512>,
0x59ac58 <exec_byte_code+9560>, 0x59ac88 <exec_byte_code+9608>, 0x59acb8 <exec_byte_code+9656>, 0x59acf8 <exec_byte_code+9720>, 0x59ad38 <exec_byte_code+9784>,
0x59ad78 <exec_byte_code+9848>, 0x59adb8 <exec_byte_code+9912>, 0x59aa40 <exec_byte_code+9024>, 0x59aa80 <exec_byte_code+9088>, 0x59aac0 <exec_byte_code+9152>,
0x59aaf0 <exec_byte_code+9200>, 0x59ab30 <exec_byte_code+9264>, 0x59ab70 <exec_byte_code+9328>, 0x59abb0 <exec_byte_code+9392>, 0x59abf0 <exec_byte_code+9456>,
0x59aa08 <exec_byte_code+8968>, 0x59a780 <exec_byte_code+8320>, 0x59a070 <exec_byte_code+6512>, 0x59a0c0 <exec_byte_code+6592>, 0x598a78 <exec_byte_code+888>,
0x598e10 <exec_byte_code+1808>, 0x598ea0 <exec_byte_code+1952>, 0x598f30 <exec_byte_code+2096>, 0x598fc0 <exec_byte_code+2240>, 0x599dc8 <exec_byte_code+5832>,
0x5993c0 <exec_byte_code+3264>, 0x5996c8 <exec_byte_code+4040>, 0x59a860 <exec_byte_code+8544>, 0x599c90 <exec_byte_code+5520>, 0x599ce0 <exec_byte_code+5600>,
0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x599d40 <exec_byte_code+5696>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>,
0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>,
0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x599d90 <exec_byte_code+5776> <repeats 64 times>}
count = 10
op = <optimized out>
vectorp = 0x1443438
stack = {
pc = 0x3631990 "\210\320\321!).\006\207",
byte_string = 21113700,
byte_string_start = 0x3631960 "\b\205\067",
next = 0x0
}
top = 0x7fff02b4fa68
result = <optimized out>
type = <optimized out>
#30 0x0000000000563732 in funcall_lambda (fun=57191557, nargs=2, arg_vector=0x7fff02b4fcc8) at eval.c:2921
val = <optimized out>
syms_left = 0
lexenv = 0
i = <optimized out>
optional = <optimized out>
rest = <optimized out>
#31 0x0000000000563b13 in Ffuncall (nargs=86946816, args=0x368ac80) at eval.c:2754
numargs = 2
val = 333
internal_args = 0x7fff02b4fcc8
count = 7
#32 0x0000000000564059 in funcall_nil (nargs=<optimized out>, args=<optimized out>) at eval.c:2332
No locals.
#33 0x000000000056205d in run_hook_with_args (nargs=3, args=0x7fff02b4fcc0, funcall=0x564050 <funcall_nil>) at eval.c:2509
global_vals = <optimized out>
sym = 50784
val = 61477811
ret = 0
#34 0x000000000056282e in run_hook_with_args (funcall=<optimized out>, args=<optimized out>, nargs=<optimized out>) at eval.c:2459
No locals.
#35 Frun_hook_with_args (args=0x7fff02b4fcc0, nargs=3) at eval.c:2374
args = 0x7fff02b4fcc0
nargs = 3
#36 run_hook_with_args_2 (hook=hook@entry=50784, arg1=arg1@entry=58591413, arg2=arg2@entry=1553398) at eval.c:2530
No locals.
#37 0x0000000000432465 in run_window_scroll_functions (window=58591413, startp=...) at xdisp.c:15110
No locals.
#38 0x000000000046443a in redisplay_window (window=58591413, just_this_one_p=false, just_this_one_p@entry=true) at xdisp.c:16382
new_vpos = 391173
startp = {
charpos = 333,
bytepos = 334
}
it = {
window = 58591413,
w = 0x37e08b0,
f = 0x1224650,
method = GET_FROM_BUFFER,
stop_charpos = 391173,
prev_stop = 391082,
base_level_stop = 391082,
end_charpos = 391173,
s = 0x0,
string_nchars = 0,
redisplay_end_trigger_charpos = 0,
multibyte_p = true,
header_line_p = false,
string_from_display_prop_p = false,
string_from_prefix_prop_p = false,
from_disp_prop_p = false,
ellipsis_p = false,
avoid_cursor_p = false,
dp = 0x0,
dpvec = 0x0,
dpend = 0x0,
dpvec_char_len = 0,
dpvec_face_id = 0,
saved_face_id = 0,
ctl_chars = {0 <repeats 16 times>},
start = {
pos = {
charpos = 388349,
bytepos = 388357
},
overlay_string_index = -1,
string_pos = {
charpos = -1,
bytepos = -1
},
dpvec_index = -1
},
current = {
pos = {
charpos = 391173,
bytepos = 391181
},
overlay_string_index = -1,
string_pos = {
charpos = -1,
bytepos = -1
},
dpvec_index = -1
},
n_overlay_strings = 0,
overlay_strings_charpos = 391173,
overlay_strings = {0 <repeats 16 times>},
string_overlays = {0 <repeats 16 times>},
string = 0,
from_overlay = 0,
stack = {{
string = 0,
string_nchars = 0,
end_charpos = 0,
stop_charpos = 0,
prev_stop = 0,
base_level_stop = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = false,
charpos = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
face_id = 0,
u = {
image = {
object = 0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
image_id = 0
},
stretch = {
object = 0
},
xwidget = {
object = 0
}
},
position = {
charpos = 0,
bytepos = 0
},
current = {
pos = {
charpos = 0,
bytepos = 0
},
overlay_string_index = 0,
string_pos = {
charpos = 0,
bytepos = 0
},
dpvec_index = 0
},
from_overlay = 0,
area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER,
paragraph_embedding = NEUTRAL_DIR,
multibyte_p = false,
string_from_display_prop_p = false,
string_from_prefix_prop_p = false,
display_ellipsis_p = false,
avoid_cursor_p = false,
bidi_p = false,
from_disp_prop_p = false,
line_wrap = TRUNCATE,
voffset = 0,
space_width = 0,
font_height = 0
}, {
string = 0,
string_nchars = 0,
end_charpos = 0,
stop_charpos = 0,
prev_stop = 0,
base_level_stop = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = false,
charpos = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
face_id = 0,
u = {
image = {
object = 0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
image_id = 0
},
stretch = {
object = 0
},
xwidget = {
object = 0
}
},
position = {
charpos = 0,
bytepos = 0
},
current = {
pos = {
charpos = 0,
bytepos = 0
},
overlay_string_index = 0,
string_pos = {
charpos = 0,
bytepos = 0
},
dpvec_index = 0
},
from_overlay = 0,
area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER,
paragraph_embedding = NEUTRAL_DIR,
multibyte_p = false,
string_from_display_prop_p = false,
string_from_prefix_prop_p = false,
display_ellipsis_p = false,
avoid_cursor_p = false,
bidi_p = false,
from_disp_prop_p = false,
line_wrap = TRUNCATE,
voffset = 0,
space_width = 0,
font_height = 0
}, {
string = 0,
string_nchars = 0,
end_charpos = 0,
stop_charpos = 0,
prev_stop = 0,
base_level_stop = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = false,
charpos = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
face_id = 0,
u = {
image = {
object = 0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
image_id = 0
},
stretch = {
object = 0
},
xwidget = {
object = 0
}
},
position = {
charpos = 0,
bytepos = 0
},
current = {
pos = {
charpos = 0,
bytepos = 0
},
overlay_string_index = 0,
string_pos = {
charpos = 0,
bytepos = 0
},
dpvec_index = 0
},
from_overlay = 0,
area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER,
paragraph_embedding = NEUTRAL_DIR,
multibyte_p = false,
string_from_display_prop_p = false,
string_from_prefix_prop_p = false,
display_ellipsis_p = false,
avoid_cursor_p = false,
bidi_p = false,
from_disp_prop_p = false,
line_wrap = TRUNCATE,
voffset = 0,
space_width = 0,
font_height = 0
}, {
string = 0,
string_nchars = 0,
end_charpos = 0,
stop_charpos = 0,
prev_stop = 0,
base_level_stop = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = false,
charpos = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
face_id = 0,
u = {
image = {
object = 0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
image_id = 0
},
stretch = {
object = 0
},
xwidget = {
object = 0
}
},
position = {
charpos = 0,
bytepos = 0
},
current = {
pos = {
charpos = 0,
bytepos = 0
},
overlay_string_index = 0,
string_pos = {
charpos = 0,
bytepos = 0
},
dpvec_index = 0
},
from_overlay = 0,
area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER,
paragraph_embedding = NEUTRAL_DIR,
multibyte_p = false,
string_from_display_prop_p = false,
string_from_prefix_prop_p = false,
display_ellipsis_p = false,
avoid_cursor_p = false,
bidi_p = false,
from_disp_prop_p = false,
line_wrap = TRUNCATE,
voffset = 0,
space_width = 0,
font_height = 0
}, {
string = 0,
string_nchars = 0,
end_charpos = 0,
stop_charpos = 0,
prev_stop = 0,
base_level_stop = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = false,
charpos = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
face_id = 0,
u = {
image = {
object = 0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
image_id = 0
},
stretch = {
object = 0
},
xwidget = {
object = 0
}
},
position = {
charpos = 0,
bytepos = 0
},
current = {
pos = {
charpos = 0,
bytepos = 0
},
overlay_string_index = 0,
string_pos = {
charpos = 0,
bytepos = 0
},
dpvec_index = 0
},
from_overlay = 0,
area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER,
paragraph_embedding = NEUTRAL_DIR,
multibyte_p = false,
string_from_display_prop_p = false,
string_from_prefix_prop_p = false,
display_ellipsis_p = false,
avoid_cursor_p = false,
bidi_p = false,
from_disp_prop_p = false,
line_wrap = TRUNCATE,
voffset = 0,
space_width = 0,
font_height = 0
}},
sp = 0,
selective = 0,
what = IT_EOB,
face_id = 0,
selective_display_ellipsis_p = true,
ctl_arrow_p = true,
face_box_p = false,
start_of_box_run_p = false,
end_of_box_run_p = false,
overlay_strings_at_end_processed_p = true,
ignore_overlay_strings_at_pos_p = false,
glyph_not_available_p = false,
starts_in_middle_of_char_p = false,
face_before_selective_p = false,
constrain_row_ascent_descent_p = false,
line_wrap = WINDOW_WRAP,
base_face_id = 0,
c = 32,
len = 1,
cmp_it = {
stop_pos = 391171,
id = -1,
ch = -2,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = false,
charpos = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
char_to_display = 32,
glyphless_method = GLYPHLESS_DISPLAY_THIN_SPACE,
image_id = 0,
xwidget = 0x0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
space_width = 0,
voffset = 0,
tab_width = 4,
font_height = 0,
object = 58622773,
position = {
charpos = 391173,
bytepos = 391181
},
truncation_pixel_width = 0,
continuation_pixel_width = 6,
first_visible_x = 0,
last_visible_x = 480,
last_visible_y = 663,
extra_line_spacing = 1,
max_extra_line_spacing = 1,
override_ascent = -1,
override_descent = 0,
override_boff = 0,
glyph_row = 0x3b39c30,
area = TEXT_AREA,
nglyphs = 1,
pixel_width = 6,
ascent = 11,
descent = 3,
max_ascent = 11,
max_descent = 3,
phys_ascent = 0,
phys_descent = 0,
max_phys_ascent = 11,
max_phys_descent = 2,
current_x = 12,
continuation_lines_width = 0,
eol_pos = {
charpos = 0,
bytepos = 0
},
current_y = 644,
first_vpos = 0,
vpos = 46,
hpos = 2,
left_user_fringe_bitmap = 0,
right_user_fringe_bitmap = 0,
left_user_fringe_face_id = 0,
right_user_fringe_face_id = 0,
bidi_p = true,
bidi_it = {
bytepos = 391181,
charpos = 391173,
ch = -1,
nchars = 1,
ch_len = 1,
type = NEUTRAL_B,
type_after_wn = NEUTRAL_B,
orig_type = NEUTRAL_B,
resolved_level = 0 '\000',
isolate_level = 0 '\000',
invalid_levels = 0,
invalid_isolates = 0,
prev = {
charpos = 391172,
type = UNKNOWN_BT,
orig_type = NEUTRAL_WS
},
last_strong = {
charpos = 391168,
type = UNKNOWN_BT,
orig_type = UNKNOWN_BT
},
next_for_neutral = {
charpos = 390500,
type = UNKNOWN_BT,
orig_type = UNKNOWN_BT
},
prev_for_neutral = {
charpos = 391173,
type = STRONG_L,
orig_type = NEUTRAL_WS
},
next_for_ws = {
charpos = -1,
type = UNKNOWN_BT,
orig_type = UNKNOWN_BT
},
bracket_pairing_pos = -1,
bracket_enclosed_type = UNKNOWN_BT,
next_en_pos = 0,
next_en_type = UNKNOWN_BT,
sos = L2R,
scan_dir = 1,
disp_pos = 391173,
disp_prop = 0,
stack_idx = 0,
level_stack = {{
next_for_neutral_pos = 0,
next_for_neutral_type = 0,
last_strong_type = 0,
prev_for_neutral_type = 0,
level = 0 '\000',
flags = 0 '\000'
} <repeats 128 times>},
string = {
lstring = 0,
s = 0x0,
schars = 0,
bufpos = 0,
from_disp_str = false,
unibyte = false
},
w = 0x37e08b0,
paragraph_dir = L2R,
separator_limit = -1,
first_elt = false,
new_paragraph = false,
frame_window_p = true
},
paragraph_embedding = NEUTRAL_DIR
}
temp_scroll_step = true
rc = 0
last_line_misfit = false
itdata = 0x7fff02b4fe10
#39 0x0000000000467a1e in redisplay_window_1 (window=window@entry=58591413) at xdisp.c:14454
No locals.
#40 0x000000000056260c in internal_condition_case_1 (bfun=0x4679f0 <redisplay_window_1>, arg=58591413, handlers=<optimized out>, hfun=0x42cf60 <redisplay_window_error>) at eval.c:1333
val = 333
c = <optimized out>
#41 0x0000000000456ad0 in redisplay_internal () at xdisp.c:14079
match_p = 176
#42 0x00000000004fa2b3 in read_char (commandflag=86946816, commandflag@entry=1, map=86617088, map@entry=86601331, prev_event=334, used_mouse_menu=0x0, used_mouse_menu@entry=0x7fff02b53dcb,
end_time=0x143ba01, end_time@entry=0x0) at keyboard.c:2477
local_getcjmp = {{
__jmpbuf = {58622773, 1564694, 29472, 1564690, 391168, 5988911, 391172, 66918760228998144},
__mask_was_saved = 45431872,
__saved_mask = {
__val = {1564694, 140733238819904, 29472, 391181, 18446744073709551615, 58622773, 5597497, 3, 401584, 58622768, 3743, 12620597, 391173, 1564694, 58622773, 0}
}
}}
save_jump = {{
__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0},
__mask_was_saved = 0,
__saved_mask = {
__val = {0 <repeats 16 times>}
}
}}
save = 13951632
previous_echo_area_message = 0
also_record = 0
reread = false
recorded = false
polling_stopped_here = false
#43 0x00000000004fca76 in read_key_sequence (keybuf=keybuf@entry=0x7fff02b53ea0, prompt=prompt@entry=0, dont_downcase_last=dont_downcase_last@entry=false,
can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false, bufsize=30) at keyboard.c:9063
interrupted_kboard = 0xd4e290
interrupted_frame = 0x1224650
key = <optimized out>
used_mouse_menu = false
echo_local_start = 0
last_real_key_start = <optimized out>
keys_local_start = <optimized out>
new_binding = <optimized out>
t = <optimized out>
echo_start = 0
keys_start = 0
current_binding = 86601331
first_event = 0
first_unbound = 31
mock_input = 0
fkey = {
parent = 17130995,
map = 17130995,
start = 0,
end = 0
}
keytran = {
parent = 12570179,
map = 12570179,
start = 0,
end = 0
}
indec = {
parent = 17131123,
map = 17131123,
start = 0,
end = 0
}
shift_translated = false
delayed_switch_frame = 0
original_uppercase = 0
original_uppercase_position = -1
dummyflag = false
starting_buffer = 0x37e8330
fake_prefixed_keys = 0
#44 0x00000000004fe6b6 in command_loop_1 () at keyboard.c:1365
cmd = <optimized out>
keybuf = {54, 78, 202, -6202091921070732288, 2822930839, -6202091921070732288, 9955464, 5377136, 73708083, 140733238820720, 73708083, 140733238821408, 0, 5652260, 317296, 73708083,
8756772, 5377136, 12340336, -6202091921070732288, 73708083, 5197970, 140733238820720, 0, 0, 5198303, 140733238821376, 5579137, 28416, 96}
i = <optimized out>
prev_modiff = 46990
prev_buffer = 0x37e8330
#45 0x0000000000562686 in internal_condition_case (bfun=bfun@entry=0x4fe4b0 <command_loop_1>, handlers=handlers@entry=19056, hfun=hfun@entry=0x4f50c0 <cmd_error>) at eval.c:1309
val = 333
c = <optimized out>
#46 0x00000000004f06ec in command_loop_2 (ignore=ignore@entry=0) at keyboard.c:1107
val = 333
#47 0x00000000005626eb in internal_catch (tag=tag@entry=45840, func=func@entry=0x4f06d0 <command_loop_2>, arg=arg@entry=0) at eval.c:1074
val = 333
c = <optimized out>
#48 0x00000000004f06a9 in command_loop () at keyboard.c:1086
No locals.
#49 0x00000000004f4cd7 in recursive_edit_1 () at keyboard.c:692
val = <optimized out>
#50 0x00000000004f4ff0 in Frecursive_edit () at keyboard.c:763
buffer = <optimized out>
#51 0x0000000000418dce in main (argc=1, argv=0x7fff02b54228) at emacs.c:1626
dummy = 140069625578752
stack_bottom_variable = 2 '\002'
skip_args = 0
rlim = {
rlim_cur = 8720000,
rlim_max = 18446744073709551615
}
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-07-19 12:04 ` Vivek Dasmohapatra
@ 2018-07-20 8:14 ` martin rudalics
2018-07-20 9:21 ` Vivek Dasmohapatra
0 siblings, 1 reply; 97+ messages in thread
From: martin rudalics @ 2018-07-20 8:14 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: 22000, David Engster
> Backtrace (attached):
>
> gdk_frame_clock_paint_idle
> …
> → gtk_container_idle_sizer
> …
> → gtk_distribute_natural_allocation
>
> Is the path, I think.
Why doesn't this process kick in after I shrink the frame width
manually such that the menu bar is cropped? Something in the course
of adding an item to the menu bar must trigger it.
>> I suppose the container respecting its wishes is that of the Emacs
>> frame's window. And if that container were a scrolled window, it
>> would not auto-resize. Do I reason correctly?
>
> Initially it's the box (vbox?) that the menubar is added to.
> Not sure that's the top level widget.
If my reading of this is correct, resizing gets passed on from one
container to its parent until the top-level widget is reached. Maybe
we could intercept that chain via gtk_container_set_resize_mode but I
don't know to which value. 'queued' doesn't sound very intriguing.
>> Only the "virtual" container we'd add would have fixed size but this
>> does not mean that it passes on the fixed size property to the menu
>> bar's widget. Inherently, this means that we would be cheating GTK
>> another time. Or am I wrong?
>
> IIUC you are right - that's how you're supposed to do it - I just don't
> know if there's a non-deprecated widget that does what we want.
>
> Worst case scenario: If I grab the scrolled window class and mutilate it
Above I meant using the gtk fixed window class for the container, not
the scrolled window one.
> till it does what we want, would you consider emacs carrying that widget
> class in its code? It shouldn't change any of the build dependencies.
>
> NOTE: FWIW even the hbox and vbox we are using are deprecated and have
> been for a while, so this whole area of code is going to need to be converted over to gtk grid at some point anyway.
I never started counting the areas of Emacs code that would require
similar treatment.
> You can suppress the scrollbars independently, but that's what restores
> the unwanted resizing behaviour in that direction: Suppress the vertical
> scrollbar and suddenly vertical size requests are honoured, suppress
> the horizontal and suddenly the menu bar can force the frame size again.
I made the silly assumption that turning off horizontal bars would
still inhibit horizontal resizing. It must be the other way round.
martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-07-20 8:14 ` martin rudalics
@ 2018-07-20 9:21 ` Vivek Dasmohapatra
2018-07-20 12:34 ` martin rudalics
0 siblings, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-07-20 9:21 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, David Engster
[-- Attachment #1: Type: TEXT/PLAIN, Size: 850 bytes --]
>> gdk_frame_clock_paint_idle
>> → gtk_container_idle_sizer
>> → gtk_distribute_natural_allocation
>
> Why doesn't this process kick in after I shrink the frame width
> manually such that the menu bar is cropped? Something in the course
It does for me. If I try to shrink the frame manually it either
pops back immediately or after a brief pause (occasionally
a long pause, but it usually "wakes up" when I interact with the UI).
>> Worst case scenario: If I grab the scrolled window class and mutilate it
>
> Above I meant using the gtk fixed window class for the container, not
> the scrolled window one.
Oh, sure - I wasn't clear - I tried adding a gtk fixed and it behaves
for our purposes the same way as an hbox - it honours resize requests,
despite its name. The fixed appears to refer to layout (positioning)
only, not size.
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-07-20 9:21 ` Vivek Dasmohapatra
@ 2018-07-20 12:34 ` martin rudalics
2018-07-20 17:44 ` Vivek Dasmohapatra
0 siblings, 1 reply; 97+ messages in thread
From: martin rudalics @ 2018-07-20 12:34 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: 22000, David Engster
>> Why doesn't this process kick in after I shrink the frame width
>> manually such that the menu bar is cropped? Something in the course
>
> It does for me. If I try to shrink the frame manually it either
> pops back immediately or after a brief pause (occasionally
> a long pause, but it usually "wakes up" when I interact with the UI).
I see. Making the default emacs -Q frame narrow enough so the Help
menu entry is not showing, maximizing and demaximizing that frame
shows the Help menu again.
> Oh, sure - I wasn't clear - I tried adding a gtk fixed and it behaves
> for our purposes the same way as an hbox - it honours resize requests,
> despite its name. The fixed appears to refer to layout (positioning)
> only, not size.
Then I'm at my wits' end. Please devise a new option like, for
example, 'gtk-menu-bar-no-auto-resize' and condition execution of your
code on the value of that variable. And please explain the trade-offs
in the doc-string of that option and that the option may be removed in
the future. Otherwise, people might claim that they do like the
auto-resizing in the unlikely case that we do find a better solution.
And we eventually have to document this in the manuals.
Thanks again for all the work, martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-07-20 12:34 ` martin rudalics
@ 2018-07-20 17:44 ` Vivek Dasmohapatra
2018-07-21 7:43 ` martin rudalics
0 siblings, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-07-20 17:44 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, David Engster
> Then I'm at my wits' end. Please devise a new option like, for
> example, 'gtk-menu-bar-no-auto-resize' and condition execution of your
> code on the value of that variable. And please explain the trade-offs
It seems to me it should be frame parameter rather than a variable:
Does that seem sensible?
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-07-20 17:44 ` Vivek Dasmohapatra
@ 2018-07-21 7:43 ` martin rudalics
2018-07-21 13:24 ` Vivek Dasmohapatra
0 siblings, 1 reply; 97+ messages in thread
From: martin rudalics @ 2018-07-21 7:43 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: 22000, David Engster
> It seems to me it should be frame parameter rather than a variable:
> Does that seem sensible?
We have to document this option so people can find it easily and I'm
not sure where and how. Basically, it should go to the Emacs manual
and we can provide a reference to section 21.11 Frame Parameters to
that effect. So something like mentioning
(add-to-list 'default-frame-alist '(gtk-menubar-no-auto-resize . t))
should do, but where? In appendix D.5.3 we say how to set the menu
and menu bar style in GTK+ and people might start searching there but
I doubt it.
In the Tooltips section we say
If Emacs is built with GTK+ support, it displays tooltips via GTK+,
using the default appearance of GTK+ tooltips. To disable this, change
the variable `x-gtk-use-system-tooltips' to `nil'. If you do this, or
if Emacs is built without GTK+ support, most attributes of the tooltip
text are specified by the `tooltip' face, and by X resources (*note X
Resources::).
Maybe we could use that as boilerplate for section 21.15 Menu Bars:
If Emacs is built with GTK+ support, the latter tries to keep all
items on the menu bar visible sometimes resizing the menu bar's frame
for that purpose. If you want to keep the frame size constant when
Emacs adds an item to the menu bar, customize the frame parameter
'x-gtk-menubar-no-auto-resize' to a non-nil value like
(add-to-list 'default-frame-alist '(x-gtk-menubar-no-auto-resize . t))
see section 21.11 ...
martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-07-21 7:43 ` martin rudalics
@ 2018-07-21 13:24 ` Vivek Dasmohapatra
2018-07-22 7:24 ` martin rudalics
0 siblings, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-07-21 13:24 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, David Engster
Cracked it!
From gtk 3.16 onwards setting the policy on the horizontal scrollbar
to EXTERNAL will suppress the scrollbar _and_ suppress the resizing
behaviour (which is effectively the old behaviour).
Since that's what I actually want, it's good enough for me.
If you think the feature would be welcome, I am happy to add a
frame-parameter driven optional scrolling behaviour for the
menu bar in case people prefer that.
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-07-21 13:24 ` Vivek Dasmohapatra
@ 2018-07-22 7:24 ` martin rudalics
2018-07-22 12:29 ` Vivek Dasmohapatra
0 siblings, 1 reply; 97+ messages in thread
From: martin rudalics @ 2018-07-22 7:24 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: 22000, David Engster
>> From gtk 3.16 onwards setting the policy on the horizontal scrollbar
> to EXTERNAL will suppress the scrollbar _and_ suppress the resizing
> behaviour (which is effectively the old behaviour).
Sounds great. Please control it via a frame parameter as you
suggested earlier. I think we can then in all conscience offer both,
the truncating and the auto-resizing behavior, as "features".
> Since that's what I actually want, it's good enough for me.
>
> If you think the feature would be welcome, I am happy to add a
> frame-parameter driven optional scrolling behaviour for the
> menu bar in case people prefer that.
Fine. Would scrolling be drivable by mouse and/or the keyboard?
martin
While you're there: Do you have any idea whether the bugs 23672, 28106
and 31223 could be in some way related to the present issue? I doubt
it because
(emacs25:16785): Gtk-WARNING **: Attempting to add a widget with type
GtkBox to a GtkMenuItem, but as a GtkBin subclass a GtkMenuItem can only
contain one widget at a time; it already contains a widget of type
GtkAccelLabel
from Bug#28106 points at us doing something silly when adding a menu
item and
(emacs25:16785): Gtk-CRITICAL **: gtk_device_grab_add: assertion
'GDK_IS_DEVICE (device)' failed
seems completely unrelated but who knows ...
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-07-22 7:24 ` martin rudalics
@ 2018-07-22 12:29 ` Vivek Dasmohapatra
2018-07-23 6:50 ` martin rudalics
0 siblings, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-07-22 12:29 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, David Engster
> Fine. Would scrolling be drivable by mouse and/or the keyboard?
You can still select the widgets by the usual M-` or <f10> followed by
arrow keys or similar - I don't think there's a key bound to scrolling
the menu bar by default but there's no reason we couldn't bind suitable
keys.
> (emacs25:16785): Gtk-WARNING **: Attempting to add a widget with type
> GtkBox to a GtkMenuItem, but as a GtkBin subclass a GtkMenuItem can only
> contain one widget at a time; it already contains a widget of type
> GtkAccelLabel
>
> from Bug#28106 points at us doing something silly when adding a menu
> item and
Probably unrelated. Souns like adding a a menu item into a "slot"
in the menu where an item already exists. I can have a look
but unless it turns out to be straightforward I won't have a much
time for this for at least a couple of weeks.
> (emacs25:16785): Gtk-CRITICAL **: gtk_device_grab_add: assertion
> 'GDK_IS_DEVICE (device)' failed
>
> seems completely unrelated but who knows ...
Also unrelated, I would say. I have less idea about what could
cause this one.
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-07-22 12:29 ` Vivek Dasmohapatra
@ 2018-07-23 6:50 ` martin rudalics
2018-10-11 13:05 ` Vivek Dasmohapatra
0 siblings, 1 reply; 97+ messages in thread
From: martin rudalics @ 2018-07-23 6:50 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: 22000, David Engster
> You can still select the widgets by the usual M-` or <f10> followed by
> arrow keys or similar - I don't think there's a key bound to scrolling
> the menu bar by default but there's no reason we couldn't bind suitable
> keys.
OK. We can look into that after you have implemented it.
>> (emacs25:16785): Gtk-WARNING **: Attempting to add a widget with type
>> GtkBox to a GtkMenuItem, but as a GtkBin subclass a GtkMenuItem can only
>> contain one widget at a time; it already contains a widget of type
>> GtkAccelLabel
>>
>> from Bug#28106 points at us doing something silly when adding a menu
>> item and
>
> Probably unrelated. Souns like adding a a menu item into a "slot"
> in the menu where an item already exists. I can have a look
> but unless it turns out to be straightforward I won't have a much
> time for this for at least a couple of weeks.
Sounds like we are exposing to Elisp something GTK woulnd't allow us
to do. Maybe someone finds a more straightforward way to reproduce
this.
>> (emacs25:16785): Gtk-CRITICAL **: gtk_device_grab_add: assertion
>> 'GDK_IS_DEVICE (device)' failed
>>
>> seems completely unrelated but who knows ...
>
> Also unrelated, I would say. I have less idea about what could
> cause this one.
I have no idea at all. For me Gtk-CRITICAL usually is a synonym for
Gtk-CRYPTICAL.
martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-07-23 6:50 ` martin rudalics
@ 2018-10-11 13:05 ` Vivek Dasmohapatra
2018-10-11 18:17 ` martin rudalics
0 siblings, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-11 13:05 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, David Engster
[-- Attachment #1: Type: TEXT/PLAIN, Size: 535 bytes --]
Hi - have been busy for a while but finally put this together.
The attached patch series:
- Lets the user control menubar scrolling via a frame parameter.
- Handles initial-frame-alist
- Handles default-frame-alist
- Handles the modify-frame-parameter path (this is secretly how initial
frames work).
- Documents the new frame parameter.
Patches prepared on top of the emacs-26 branch but should apply to master
too.
Let me know if the series needs any revision (I have already done the
copyright-assignment dance).
[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 4396 bytes --]
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-11 13:05 ` Vivek Dasmohapatra
@ 2018-10-11 18:17 ` martin rudalics
2018-10-11 18:27 ` martin rudalics
2018-10-11 20:51 ` Vivek Dasmohapatra
0 siblings, 2 replies; 97+ messages in thread
From: martin rudalics @ 2018-10-11 18:17 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: 22000, David Engster
> The attached patch series:
>
> - Lets the user control menubar scrolling via a frame parameter.
> - Handles initial-frame-alist
> - Handles default-frame-alist
> - Handles the modify-frame-parameter path (this is secretly how initial
> frames work).
> - Documents the new frame parameter.
>
> Patches prepared on top of the emacs-26 branch but should apply to master
> too.
Thank you very much. After a quick first evaluation I can confirm
that the menu bar gets truncated and the frame is not resized when
switching to dired with a sufficiently narrow frame.
I'm currently struggling with the following problems:
(1) 0003-GTK3-menubar-resize-scrollbar-behaviour-now-driven-b.patch
doesn't apply here on master.
(2) With all patches applied to the emacs-26 branch I get no initial
menu bar and toggling 'menu-bar-mode' won't get it either.
(3) With patches 1 and 2 applied to master, my menu bar takes more
empty space above and below the text than before. I had this problem
earlier but I forgot the context. So this might be related to some
part of my setup here but is certainly triggered by the patch.
I'll get back to you as soon as I find out more about (2) and (3).
Please prepare patches that apply on master so people who use master
only can test them. And obviously everybody is urged to test this fix
for that longstanding bug.
Thanks again, martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-11 18:17 ` martin rudalics
@ 2018-10-11 18:27 ` martin rudalics
2018-10-11 18:48 ` Vivek Dasmohapatra
2018-10-11 20:51 ` Vivek Dasmohapatra
1 sibling, 1 reply; 97+ messages in thread
From: martin rudalics @ 2018-10-11 18:27 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: 22000, David Engster
> (3) With patches 1 and 2 applied to master, my menu bar takes more
> empty space above and below the text than before. I had this problem
> earlier but I forgot the context. So this might be related to some
> part of my setup here but is certainly triggered by the patch.
I'm too silly. We've been discussing this problem already in the
current context, so there's nothing new about it. But the missing
menu bar with patches 0003 and 0004 applied I mentioned earlier is
something new IIUC.
martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-11 18:27 ` martin rudalics
@ 2018-10-11 18:48 ` Vivek Dasmohapatra
0 siblings, 0 replies; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-11 18:48 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, David Engster
> But the missing menu bar with patches 0003 and 0004 applied I
> mentioned earlier is something new IIUC.
Hm. I tested on emacs26 and had a menu bar. Does it happen with
emacs -q and/or -Q ?
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-11 18:17 ` martin rudalics
2018-10-11 18:27 ` martin rudalics
@ 2018-10-11 20:51 ` Vivek Dasmohapatra
2018-10-12 8:44 ` martin rudalics
1 sibling, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-11 20:51 UTC (permalink / raw)
To: 22000; +Cc: David Engster
[-- Attachment #1: Type: TEXT/PLAIN, Size: 365 bytes --]
> Please prepare patches that apply on master so people who use master
> only can test them.
Patchset attached.
Rebased on:
5bd8cfc14d4b0c78c07e65a583f42a10c4cbc06d
Fix mishandling of symbols that look like numbers
Built and briefly tested locally.
I still haven't been able to reproduced the missing menu bar symptom
you described, with or without -q.
[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 4412 bytes --]
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-11 20:51 ` Vivek Dasmohapatra
@ 2018-10-12 8:44 ` martin rudalics
2018-10-12 12:47 ` Vivek Dasmohapatra
2018-10-12 18:16 ` Vivek Dasmohapatra
0 siblings, 2 replies; 97+ messages in thread
From: martin rudalics @ 2018-10-12 8:44 UTC (permalink / raw)
To: Vivek Dasmohapatra, 22000; +Cc: David Engster
> Patchset attached.
>
> Rebased on:
>
> 5bd8cfc14d4b0c78c07e65a583f42a10c4cbc06d
> Fix mishandling of symbols that look like numbers
>
> Built and briefly tested locally.
The patchset still doesn't apply to master since master has evolved
differently. I get:
Hunk #1 succeeded at 5671 (offset 11 lines).
Hunk #2 succeeded at 5690 (offset 11 lines).
Checking patch src/gtkutil.c...
error: while searching for:
struct x_output *x = f->output_data.x;
GtkRequisition req;
GtkScrolledWindow *sw;
if (!x->menubar_widget || gtk_widget_get_mapped (x->menubar_widget))
return;
error: patch failed: src/gtkutil.c:3455
error: src/gtkutil.c: patch does not apply
Checking patch src/xfns.c...
error: while searching for:
NILP (Vtool_bar_mode)
? make_number (0) : make_number (1),
NULL, NULL, RES_TYPE_NUMBER);
x_default_parameter (f, parms, Qbuffer_predicate, Qnil,
"bufferPredicate", "BufferPredicate",
RES_TYPE_SYMBOL);
error: patch failed: src/xfns.c:3888
error: src/xfns.c: patch does not apply
and in fact
GtkScrolledWindow *sw;
has been removed from the former and the latter is now
NILP (Vtool_bar_mode)
? make_fixnum (0) : make_fixnum (1),
NULL, NULL, RES_TYPE_NUMBER);
x_default_parameter (f, parms, Qbuffer_predicate, Qnil,
"bufferPredicate", "BufferPredicate",
RES_TYPE_SYMBOL);
So in fact we would need two different patch sets here. Let's
stick with the release version for the moment:
Here patches 0001 and 0002 fix the resize problem but I get a too large
menu bar which makes GTK builds pretty unusable. Didn't we agree that
you make the fix optional? That is, one option value (say 'truncate')
for users who want the resize problem get fixed and who are willing to
pay for that with a higher menu bar. And one option value (say
'resize') for users who can live with the resizing problem but care more
about the height of the menu bar.
> I still haven't been able to reproduced the missing menu bar symptom
> you described, with or without -q.
Patches 0003, 0004 and 0005 make the menu bar invisible at start (with
emacs -Q) and don't allow to bring it back via M-x: menu-bar-mode. I
can get it back with my customized Emacs, though. Any ideas (this is
GTK version 3.4.2)?
Thanks, martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-12 8:44 ` martin rudalics
@ 2018-10-12 12:47 ` Vivek Dasmohapatra
2018-10-12 18:12 ` martin rudalics
2018-10-12 18:16 ` Vivek Dasmohapatra
1 sibling, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-12 12:47 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, David Engster
> The patchset still doesn't apply to master since master has evolved
> differently. I get:
Where exactly (commit id) are you applying the patch?
[cut]
> GtkScrolledWindow *sw;
>
> has been removed from the former and the latter is now
GtkScrolledWindow is introduced by the patch series - I'm confused:
Which patch series did you try and where?
> Here patches 0001 and 0002 fix the resize problem but I get a too large
> menu bar which makes GTK builds pretty unusable. Didn't we agree that
> you make the fix optional? That is, one option value (say 'truncate')
I can make truncation the default behaviour (in fact it is),
the problem is the presence of the scrolledwindow which is necessary
for the fix introduces extra padding. I'm not sure there's a way to fix
that (well, I guess there is but it's a little tricky as it means the
scrolledwindow has to appear and disappear entirely from the widget
hierarchy).
I might be able to fix it with a style change, if I can defeat the gtk3 docs
and figure out if/how to set a style property on a widget.
> for users who want the resize problem get fixed and who are willing to
> pay for that with a higher menu bar. And one option value (say
> 'resize') for users who can live with the resizing problem but care more
> about the height of the menu bar.
> Patches 0003, 0004 and 0005 make the menu bar invisible at start (with
> emacs -Q) and don't allow to bring it back via M-x: menu-bar-mode. I
> can get it back with my customized Emacs, though. Any ideas (this is
> GTK version 3.4.2)?
That's pretty old... even on oldstable I have 3.14. I can try and find a
system with that version of GTK, wondering if it's a GTK bug.
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-12 12:47 ` Vivek Dasmohapatra
@ 2018-10-12 18:12 ` martin rudalics
2018-10-12 18:25 ` Vivek Dasmohapatra
2018-10-12 18:34 ` Vivek Dasmohapatra
0 siblings, 2 replies; 97+ messages in thread
From: martin rudalics @ 2018-10-12 18:12 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: 22000, David Engster
>> The patchset still doesn't apply to master since master has evolved
>> differently. I get:
>
> Where exactly (commit id) are you applying the patch?
I don't recall - somewhen with today's master.
>> GtkScrolledWindow *sw;
>>
>> has been removed from the former and the latter is now
>
> GtkScrolledWindow is introduced by the patch series - I'm confused:
> Which patch series did you try and where?
OK (I only tried to second guess the cause of the error messages
probably by looking at a not yet patched version). But since the
patch applies in its entirety against the release version, the problem
must be master-specific. In either case don't bother.
> I can make truncation the default behaviour (in fact it is),
> the problem is the presence of the scrolledwindow which is necessary
> for the fix
You explained that earlier.
> introduces extra padding. I'm not sure there's a way to fix that (well, I guess there is but it's a little tricky as it means the
> scrolledwindow has to appear and disappear entirely from the widget hierarchy).
Why would it have to do that?
> I might be able to fix it with a style change, if I can defeat the gtk3 docs
> and figure out if/how to set a style property on a widget.
Let's postpone that for the moment.
> That's pretty old... even on oldstable I have 3.14. I can try and find a system with that version of GTK, wondering if it's a GTK bug.
We already care for 3.3.6 and even 3.2.0. Our usual problems with GTK
are the newer versions (since they often deprecate what we wrote).
Anyway, the primary warning I see is the following:
(emacs:4182): Gtk-WARNING **: gtk_scrolled_window_add(): cannot add non scrollable widget use gtk_scrolled_window_add_with_viewport() instead
Now gtk_scrolled_window_add_with_viewport is deprecated since GTK 3.8
so there's no use bothering with this _if_ we make truncation
optional. But for some reason we don't.
I do not understand the following part of your changes:
#if GTK_CHECK_VERSION (3, 16, 0)
GtkPolicyType menuscroll_policy = GTK_POLICY_EXTERNAL;
#else
GtkPolicyType menuscroll_policy = GTK_POLICY_NEVER;
#endif
...
menuscroll = get_frame_param (f, Qmenu_bar_scrollbar);
if (EQ (menuscroll, Qautomatic))
menuscroll_policy = GTK_POLICY_AUTOMATIC;
else if (EQ (menuscroll, Qalways))
menuscroll_policy = GTK_POLICY_ALWAYS;
Doesn't this mean that when a frame has the 'menu-bar-scrollbar'
parameter set we effectively override the version check above?
Immediately after that you unconditionally do
/* Put the menu bar inside a scrolled window so that adding items
to the menu bar (such as when entering dired mode or activating
a minor more) does not trigger a frame resize:*/
x->menubar_viewport = gtk_scrolled_window_new(NULL, NULL);
sw = GTK_SCROLLED_WINDOW (x->menubar_viewport);
gtk_scrolled_window_set_policy (sw, menuscroll_policy, GTK_POLICY_AUTOMATIC);
so we always put this into a _scrolled_ window regardless of whether
GTK can handle that. That's the crucial problem here.
So I think we need two things:
(1) Give the user a variable and a frame parameter that controls
whether the menu bar shall be truncated when the frame gets smaller or
allows to resize the frame. I would call that parameter
'gtk-menu-bar-resize' and the value would be nil by default which
means "truncate" while t would mean "auto-resize the frame". In
addition we could add a minor mode like 'menu-bar-resize-mode' to
provide a default for users who don't want to set that individually
for each frame.
(2) Give the user a variable and a frame parameter that controls
whether the menu bar shall be scrollable when it can be truncated. I
would call that parameter 'gtk-menu-bar-scroll' and the value would be
nil by default which means not to scroll while t would mean to scroll.
In addition we could add a minor mode like 'menu-bar-scroll-mode' to
provide a default for users who don't want to set that individually.
In short: (1) would allow users to specify whether they want a
scrollable menu bar window. (2) would allow them to specify whether
that window should be really scrollable. And we should make the menu
bar scrollable and thus provide (1) iff GTK supports it (so GTK 3.8 is
probably the minimum version where we can do that). And for GTK < 3.8
nothing would change at all to what we have now.
Find a list of my current GTK bugs below.
Thanks, martin
The GTK bugs are currently on Emacs master with patches 0001 and 0002
only (this shows the menu bar initially):
(emacs:4182): Gtk-WARNING **: gtk_scrolled_window_add(): cannot add non scrollable widget use gtk_scrolled_window_add_with_viewport() instead
(emacs:4182): Gtk-CRITICAL **: gtk_scrollable_get_vscroll_policy: assertion `GTK_IS_SCROLLABLE (scrollable)' failed
(emacs:4182): Gtk-CRITICAL **: gtk_scrollable_get_hscroll_policy: assertion `GTK_IS_SCROLLABLE (scrollable)' failed
...
On Emacs 26 with the entire patch set (this is the one where the menu
bar is not shown initially).
(emacs:3730): Gtk-WARNING **: gtk_scrolled_window_add(): cannot add non scrollable widget use gtk_scrolled_window_add_with_viewport() instead
(emacs:3730): Gtk-CRITICAL **: gtk_scrollable_get_vscroll_policy: assertion `GTK_IS_SCROLLABLE (scrollable)' failed
(emacs:3730): Gtk-CRITICAL **: gtk_widget_get_preferred_width_for_height: assertion `height >= 0' failed
(emacs:3730): Gtk-CRITICAL **: gtk_widget_get_preferred_width_for_height: assertion `height >= 0' failed
(emacs:3730): Gtk-CRITICAL **: gtk_widget_get_preferred_width_for_height: assertion `height >= 0' failed
(emacs:3730): Gtk-CRITICAL **: gtk_widget_get_preferred_width_for_height: assertion `height >= 0' failed
(emacs:3730): Gtk-CRITICAL **: gtk_widget_get_preferred_width_for_height: assertion `height >= 0' failed
(emacs:3730): Gtk-CRITICAL **: gtk_widget_get_preferred_width_for_height: assertion `height >= 0' failed
(emacs:3730): Gtk-CRITICAL **: gtk_widget_get_preferred_width_for_height: assertion `height >= 0' failed
(emacs:3730): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width 32632 and height -1
(emacs:3730): Gtk-CRITICAL **: gtk_widget_get_preferred_width_for_height: assertion `height >= 0' failed
(emacs:3730): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width 32622 and height -3
(emacs:3730): Gtk-CRITICAL **: gtk_widget_get_preferred_width_for_height: assertion `height >= 0' failed
(emacs:3730): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width 32632 and height -1
(emacs:3730): Gtk-CRITICAL **: gtk_widget_get_preferred_width_for_height: assertion `height >= 0' failed
(emacs:3730): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width 32622 and height -3
...
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-12 8:44 ` martin rudalics
2018-10-12 12:47 ` Vivek Dasmohapatra
@ 2018-10-12 18:16 ` Vivek Dasmohapatra
1 sibling, 0 replies; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-12 18:16 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, David Engster
[-- Attachment #1: Type: TEXT/PLAIN, Size: 562 bytes --]
> for users who want the resize problem get fixed and who are willing to
> pay for that with a higher menu bar. And one option value (say
> 'resize') for users who can live with the resizing problem but care more
> about the height of the menu bar.
I've used a CSS provider to strip away all the extra space. I have to put
a little bit back to prevent a UI focus bug when the scrollbar is present
but it's still a lot more compact than it was: Attached screenshot shows
new / new+scrollbar / old - as you can see new w/o scrollbars is the same
height as old.
[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 6036 bytes --]
[-- Attachment #3: Type: IMAGE/png, Size: 4788 bytes --]
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-12 18:12 ` martin rudalics
@ 2018-10-12 18:25 ` Vivek Dasmohapatra
2018-10-13 8:20 ` martin rudalics
2018-10-12 18:34 ` Vivek Dasmohapatra
1 sibling, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-12 18:25 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, David Engster
>> I might be able to fix it with a style change, if I can defeat the gtk3
> docs
>> and figure out if/how to set a style property on a widget.
>
> Let's postpone that for the moment.
It's done, see latest patchset.
> Anyway, the primary warning I see is the following:
>
> (emacs:4182): Gtk-WARNING **: gtk_scrolled_window_add(): cannot add non
> scrollable widget use gtk_scrolled_window_add_with_viewport() instead
Aha! I think I know what's happening. You used to have to add the viewport
manually for widgets that weren't inherently scrollable. I'll add
some #if guarded code for the earlier GTK versions.
> #if GTK_CHECK_VERSION (3, 16, 0)
> GtkPolicyType menuscroll_policy = GTK_POLICY_EXTERNAL;
> #else
> GtkPolicyType menuscroll_policy = GTK_POLICY_NEVER;
> #endif
> ...
> menuscroll = get_frame_param (f, Qmenu_bar_scrollbar);
> if (EQ (menuscroll, Qautomatic))
> menuscroll_policy = GTK_POLICY_AUTOMATIC;
> else if (EQ (menuscroll, Qalways))
> menuscroll_policy = GTK_POLICY_ALWAYS;
>
> Doesn't this mean that when a frame has the 'menu-bar-scrollbar'
> parameter set we effectively override the version check above?
Nope - EXTERNAL is the new policy which actually does what we want:
truncated menu bar. That is the default behaviour, except on earlier
GTK versions where we get the current frame-jitter behaviour by default.
We only override if the frame paramter is set to 'always or 'automatic,
neither of which is the default.
> so we always put this into a _scrolled_ window regardless of whether
> GTK can handle that. That's the crucial problem here.
The problem is that earlier GTK versions need a viewport added explicitly
between the scrollbar and the menubar - that's easy enough to do now that
I know that's what's needed.
> In short: (1) would allow users to specify whether they want a
> scrollable menu bar window. (2) would allow them to specify whether
> that window should be really scrollable. And we should make the menu
> bar scrollable and thus provide (1) iff GTK supports it (so GTK 3.8 is
> probably the minimum version where we can do that). And for GTK < 3.8
> nothing would change at all to what we have now.
I think we can achieve all of the above with a couple of lines to add the
intermediate viewport for GTK versions that require it. Otherwise we
already have the default behaviour you described (I think).
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-12 18:12 ` martin rudalics
2018-10-12 18:25 ` Vivek Dasmohapatra
@ 2018-10-12 18:34 ` Vivek Dasmohapatra
1 sibling, 0 replies; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-12 18:34 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, David Engster
[-- Attachment #1: Type: TEXT/PLAIN, Size: 47 bytes --]
Try adding this to the latest -compact series.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: TEXT/x-diff; name=0008-Manually-wrap-the-menu-bar-in-a-viewport-for-GTK-3.8.patch, Size: 1060 bytes --]
From 9160f9f1ae7d9f7501a3e6fb5113ba115fb8ccb4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vivek=20Das=C2=A0Mohapatra?= <vivek@collabora.com>
Date: Fri, 12 Oct 2018 19:31:05 +0100
Subject: [PATCH 8/8] Manually wrap the menu bar in a viewport for GTK 3.8-
Versions of GTK prior to 3.8 cannot add non-scrollable
widgets to a scrolled window without a manually added viewport.
---
src/gtkutil.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/gtkutil.c b/src/gtkutil.c
index 3498d14fe1..cd8438f86a 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -3547,7 +3547,11 @@ xg_update_frame_menubar (struct frame *f)
gtk_scrolled_window_set_overlay_scrolling (sw, FALSE);
#endif
+#if GTK_CHECK_VERSION (3, 8, 0)
gtk_container_add (GTK_CONTAINER (sw), x->menubar_widget);
+#else
+ gtk_scrolled_window_add_with_viewport (sw, x->menubar_widget);
+#endif
gtk_box_pack_start (GTK_BOX (x->vbox_widget), GTK_WIDGET(sw), FALSE, FALSE, 0);
gtk_box_reorder_child (GTK_BOX (x->vbox_widget), GTK_WIDGET(sw), 0);
--
2.11.0
^ permalink raw reply related [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-12 18:25 ` Vivek Dasmohapatra
@ 2018-10-13 8:20 ` martin rudalics
2018-10-13 10:03 ` Vivek Dasmohapatra
2018-10-15 13:57 ` Vivek Dasmohapatra
0 siblings, 2 replies; 97+ messages in thread
From: martin rudalics @ 2018-10-13 8:20 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: 22000, David Engster
>>> I might be able to fix it with a style change, if I can defeat the gtk3
>> docs
>>> and figure out if/how to set a style property on a widget.
>>
>> Let's postpone that for the moment.
>
> It's done, see latest patchset.
Commented below.
>> Anyway, the primary warning I see is the following:
>>
>> (emacs:4182): Gtk-WARNING **: gtk_scrolled_window_add(): cannot add non scrollable widget use gtk_scrolled_window_add_with_viewport() instead
>
> Aha! I think I know what's happening. You used to have to add the viewport
> manually for widgets that weren't inherently scrollable. I'll add
> some #if guarded code for the earlier GTK versions.
With that code it works with the non-compact series without warnings
and error messages under GTK 3.4.2. However with the compact series I
can't compile because GTK_POLICY_EXTERNAL is undefined for versions
less than 3.16.0. If, to fix that, I do
+ switch (scroll_policy)
+ {
+#if GTK_CHECK_VERSION (3, 16, 0)
+ case GTK_POLICY_EXTERNAL:
+#endif
+ case GTK_POLICY_NEVER:
+ gtk_style_context_remove_class (style, "mbscroll");
+ gtk_style_context_add_class (style, "mbtrunc");
+ break;
+ default:
+ gtk_style_context_remove_class (style, "mbtrunc");
+ gtk_style_context_add_class (style, "mbscroll");
+ }
then there is no compaction - at least by default. Is there a
parameter I would have to set via 'default-frame-alist' here?
Thanks, martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-13 8:20 ` martin rudalics
@ 2018-10-13 10:03 ` Vivek Dasmohapatra
2018-10-15 13:57 ` Vivek Dasmohapatra
1 sibling, 0 replies; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-13 10:03 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, David Engster
> then there is no compaction - at least by default. Is there a
> parameter I would have to set via 'default-frame-alist' here?
Should be unconditional. I'll see what I can do, I may have to spin
up a chroot with 3.4.x and investigate.
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-13 8:20 ` martin rudalics
2018-10-13 10:03 ` Vivek Dasmohapatra
@ 2018-10-15 13:57 ` Vivek Dasmohapatra
2018-10-15 18:23 ` martin rudalics
1 sibling, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-15 13:57 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, David Engster
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1029 bytes --]
GTK 3.16 and later:
The menu bar is always in a scrollwed window . In the default mode,
the menu bar is truncated when it tries to grow wider than the frame.
CSS is used to strip away the excess space this introduces.
In 'always or 'automatic mode, the CSS is relaxed slightly to work
around a GTK focus glitch, but otherwise the widget setup is identical.
The menubar will have a scrollbar either always, or when it tries to
grow too wide.
Before GTK 3.16:
When in 'always or 'automatic mode, the menu bar will be in a scrolled
window. The extra space cannot be properly ameliorated with CSS
styling as this does not seem to work well. In the default mode,
the scrolled window is not present - the menu bar is dynamically
re-parented between the scrolled window (which is created on demand)
and the emacs pane (vbox widget) when the menu bar scrolling mode
is changed.
At these GTK versions truncation does not work, so the menu bar
frame size jitter big persists in the default mode.
[ Tested on gtk 3.22.11 and 3.4.2 ]
[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 7740 bytes --]
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-15 13:57 ` Vivek Dasmohapatra
@ 2018-10-15 18:23 ` martin rudalics
2018-10-16 1:19 ` Vivek Dasmohapatra
2018-10-16 18:58 ` Vivek Dasmohapatra
0 siblings, 2 replies; 97+ messages in thread
From: martin rudalics @ 2018-10-15 18:23 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: 22000, David Engster
> When in 'always or 'automatic mode, the menu bar will be in a scrolled
> window. The extra space cannot be properly ameliorated with CSS
> styling as this does not seem to work well. In the default mode,
> the scrolled window is not present - the menu bar is dynamically
> re-parented between the scrolled window (which is created on demand)
> and the emacs pane (vbox widget) when the menu bar scrolling mode
> is changed.
>
> At these GTK versions truncation does not work, so the menu bar
> frame size jitter big persists in the default mode.
Very good. I can get my normal menu bar back with GTK 3.4.2. But I'm
still inclined to ask you to do the following:
- Provide the forced frame resize behavior for GTK >= 3.16 as well. I
think the corresponding value of the menu-bar-scrollbar parameter
should be something like 'forced-resize' in that case.
- IIUC there's now no way for GTK < 3.16 to get the
'menu-bar-scrollbar' nil behavior. No great deal but if you added
'forced-resize', then a user who does not like the large menu bar
can get that easily by using 'forced-resize' instead. The default
for GTK < 3.16 would still be nil.
+The behaviour of GTK menu bars when they would otherwise grow wider than
"behaviour" is "behavior" in the Emacs manual.
+the frame. Valid values are @code{always} to draw a scrollbar whether or
Please use two spaces after a sentence end in documentations.
+not it is required; @code{automatic} to draw one only when necessary; and
+@code{nil} (or any other value) for the default behaviour, which is to
+truncate the scrollbar if possible (GTK 3.16 and later). Prior to GTK 3.16
+the default behaviour is to force a frame resize: This is a GTK limitation.
This is too terse. In particular "nil" also stands for not drawing a
scrollbar and that should stated. And note that the forced frame
resize occurs only when a new menu bar shall be drawn. Even now a
user can alway truncate the menu bar by manually resizing the frame.
This should be somehow mentioned in the text to avoid confusions.
Finally, I would provide a 'menu-bar-scrollbar-mode' that would add
the 'menu-bar-scrollbar' parameter automatically. Please have a look
at how for example 'window-divider-mode' (which is off by default)
does that. Then we could also add an entry in the "Show/Hide" entry
of the Options menu. Provided we can add/remove a menu bar scrollbar
dynamically to/from an existing frame. No great harm if we can't, but
then we should mention that fact somewhere.
> [ Tested on gtk 3.22.11 and 3.4.2 ]
People are strongly urged to test this with their GTK builds. At
least one or two feedbacks would be awfully welcome. Maybe you could
also provide one large patch which includes all changes?
BTW, compiling with GTK 3.4.2 gives a spurious
../../src/gtkutil.c: In function ‘xg_update_frame_menubar’:
../../src/gtkutil.c:3609:22: warning: variable ‘sw’ set but not used [-Wunused-but-set-variable]
warning here.
Thanks, martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-15 18:23 ` martin rudalics
@ 2018-10-16 1:19 ` Vivek Dasmohapatra
2018-10-16 8:47 ` martin rudalics
2018-10-16 18:58 ` Vivek Dasmohapatra
1 sibling, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-16 1:19 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, David Engster
On Mon, 15 Oct 2018, martin rudalics wrote:
> - IIUC there's now no way for GTK < 3.16 to get the
> 'menu-bar-scrollbar' nil behavior. No great deal but if you added
> 'forced-resize', then a user who does not like the large menu bar
> can get that easily by using 'forced-resize' instead. The default
> for GTK < 3.16 would still be nil.
Assuming nil behaviour = menu bar is truncated when too wide but
has no scrollbar and no extra padding - GTK < 3.16 can't do this
without either implementing a custom widget or providing the
equivalent of GTK_POLICY_EXTERNAL.
3.16+:
always - scrollbar always present, menu bar would be vertically
padded but we compress it with CSS
automatic - similar, but scrollbar disappears when not required
forced-resize - no scrollbar and no padding. frame will resize
semi-predictably when the menu bar's natural size
exceeds that of the frame.
nil - no scrollbar, menu would be vertically padded but
we compress it with CSS. menu bar is truncated
if it tries to extend past the frame edge.
3.16-:
always - scrollbar always present, menu bar is vertically
padded. does not appear to bepossible to fix
this with CSS.
automatic - similar, but scrollbar disappears when not required
forced-resize - no scrollbar and no padding. frame will resize
semi-predictably when the menu bar's natural size
exceeds that of the frame.
nil - identical to forced-resize for these GTK versions
[cut]
> resize occurs only when a new menu bar shall be drawn. Even now a
> user can alway truncate the menu bar by manually resizing the frame.
> This should be somehow mentioned in the text to avoid confusions.
To clarify - a user can _try_ to manually resize the frame but sooner
or later (usually sooner) the gdk timer fires and gtk notices that
the menu bar wants more space and resizes the frame. Depending on
your exact GTK version and the phase of the moon you _may_ be able
to dodge this forced resize but you cannot reliably do so.
> of the Options menu. Provided we can add/remove a menu bar scrollbar
> dynamically to/from an existing frame. No great harm if we can't
We can, I've been testing this to make sure it works.
Currently working on updating the patches to address these points (and the
others to which I have not replied specifically here) - will probably
send an updated series tomorrow (2018-10-16)
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-16 1:19 ` Vivek Dasmohapatra
@ 2018-10-16 8:47 ` martin rudalics
0 siblings, 0 replies; 97+ messages in thread
From: martin rudalics @ 2018-10-16 8:47 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: 22000, David Engster
> Assuming nil behaviour = menu bar is truncated when too wide but
> has no scrollbar and no extra padding - GTK < 3.16 can't do this
> without either implementing a custom widget or providing the
> equivalent of GTK_POLICY_EXTERNAL.
>
> 3.16+:
> always - scrollbar always present, menu bar would be vertically
> padded but we compress it with CSS
> automatic - similar, but scrollbar disappears when not required
> forced-resize - no scrollbar and no padding. frame will resize
> semi-predictably when the menu bar's natural size
> exceeds that of the frame.
> nil - no scrollbar, menu would be vertically padded but
> we compress it with CSS. menu bar is truncated
> if it tries to extend past the frame edge.
>
> 3.16-:
> always - scrollbar always present, menu bar is vertically
> padded. does not appear to bepossible to fix
> this with CSS.
> automatic - similar, but scrollbar disappears when not required
> forced-resize - no scrollbar and no padding. frame will resize
> semi-predictably when the menu bar's natural size
> exceeds that of the frame.
> nil - identical to forced-resize for these GTK versions
Good. We could for the 3.16- nil case do what you did earlier with
the extra padding but I think that having this as default would harm
more than do any good. So let's stick to this your proposal - it's
the most sane approach I can think of at the moment.
> To clarify - a user can _try_ to manually resize the frame but sooner
> or later (usually sooner) the gdk timer fires and gtk notices that
> the menu bar wants more space and resizes the frame. Depending on
> your exact GTK version and the phase of the moon you _may_ be able
> to dodge this forced resize but you cannot reliably do so.
Yes. I forgot about this timer issue.
>> of the Options menu. Provided we can add/remove a menu bar scrollbar
>> dynamically to/from an existing frame. No great harm if we can't
>
> We can, I've been testing this to make sure it works.
Fine.
> Currently working on updating the patches to address these points (and the others to which I have not replied specifically here) - will probably
> send an updated series tomorrow (2018-10-16)
We'll then have to discuss with Eli whether to apply this to Emacs
26.2 or to master.
Thanks, martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-15 18:23 ` martin rudalics
2018-10-16 1:19 ` Vivek Dasmohapatra
@ 2018-10-16 18:58 ` Vivek Dasmohapatra
2018-10-17 7:29 ` martin rudalics
1 sibling, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-16 18:58 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, David Engster
On Mon, 15 Oct 2018, martin rudalics wrote:
> Finally, I would provide a 'menu-bar-scrollbar-mode' that would add
> the 'menu-bar-scrollbar' parameter automatically. Please have a look
> at how for example 'window-divider-mode' (which is off by default)
I have a command which cycles through the available scrollbar modes
and sets the "next" value in default-frame-alist & applies it to all
extant frames: However I'm aware that -mode means something specific
in elisp and this is not that. It's not a toggle as most minor modes
are but a 4-state (or 3-state for 3.16-).
Any suggestions on a name? Or is -mode still acceptable?
(currently called `menu-bar-scrollbar-mode' since I had
to call it _something_).
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-16 18:58 ` Vivek Dasmohapatra
@ 2018-10-17 7:29 ` martin rudalics
2018-10-18 1:02 ` Vivek Dasmohapatra
0 siblings, 1 reply; 97+ messages in thread
From: martin rudalics @ 2018-10-17 7:29 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: 22000, David Engster
> I have a command which cycles through the available scrollbar modes
> and sets the "next" value in default-frame-alist & applies it to all
> extant frames: However I'm aware that -mode means something specific
> in elisp and this is not that. It's not a toggle as most minor modes
> are but a 4-state (or 3-state for 3.16-).
>
> Any suggestions on a name? Or is -mode still acceptable?
> (currently called `menu-bar-scrollbar-mode' since I had
> to call it _something_).
Here I have for example the following tri-state -mode variable:
scroll-bar-mode is a variable defined in ‘scroll-bar.el’.
Its value is ‘right’
Documentation:
Specify whether to have vertical scroll bars, and on which side.
Possible values are nil (no scroll bars), ‘left’ (scroll bars on left)
and ‘right’ (scroll bars on right).
So I see no problem in making 'menu-bar-scrollbar-mode' a multistate
variable. Maybe one day someone wants to add a ">>" in the top right
corner to reveal further menu entries.
martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-17 7:29 ` martin rudalics
@ 2018-10-18 1:02 ` Vivek Dasmohapatra
2018-10-18 8:06 ` martin rudalics
0 siblings, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-18 1:02 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, David Engster
[-- Attachment #1: Type: TEXT/PLAIN, Size: 89 bytes --]
New patch series - I think this has all the features and functionality
discussed so far.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: TEXT/x-diff; name=0001-GTK3-menu-bars-force-frame-resizing-Bug-22000.patch, Size: 16011 bytes --]
From c9e24d6bf4d3d5baae9bb4dade97cfcb8a5ecafc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vivek=20Das=C2=A0Mohapatra?= <vivek@collabora.com>
Date: Sun, 15 Jul 2018 18:59:59 +0100
Subject: [PATCH 1/3] GTK3 menu bars force frame resizing (Bug#22000)
Menu bars force the frame they are in to resize when the menu bar
width exceeds the frame width, both at the point the menu bar grows
past the frame width and whenever the gtk idle resize callback is
triggered.
The effect is that the user's frame width is effectively ignored, and
emacs will semi-predictably resize itself to accommodate the menu bar.
This effect can be suppressed by wrapping the menu bar in a scrollable
window.
This behaviour is controlled by the `menu-bar-scrollbar' parameter
which may have a value of 'automatic, 'always, 'forced-resize or
anything else (equivalent to nil).
Limitations in earlier versions of GTK mean that there are
some version-dependent differences in behaviour.
GTK 3.16 and later:
The menu bar is always in a scrolled window . In the default mode
the menu bar is truncated when it tries to grow wider than the frame.
CSS is used to strip away the excess space this introduces.
In 'always or 'automatic mode, the CSS is relaxed slightly to work
around a GTK focus glitch, but otherwise the widget setup is identical.
The menubar will have a scrollbar either always, or when it tries to
grow too wide.
In 'forced-resize mode the frame-size-jitter behaviour described in
bug #22000 is preserved.
Before GTK 3.16:
When in 'always or 'automatic mode, the menu bar will be in a scrolled
window. The extra space cannot be properly ameliorated with CSS
styling as this does not seem to work well.
In the default mode, the scrolled window is not present - the menu bar
is dynamically re-parented between the scrolled window (which is
created on demand) and the emacs pane (vbox widget) when the menu bar
scrolling mode is changed.
In these versions of GTK the menu-bar truncation behaviour is not
easily achievable, so the default mode is identical to 'forced-resize
mode.
---
src/frame.c | 7 ++
src/gtkutil.c | 203 +++++++++++++++++++++++++++++++++++++++++++++++++++++++---
src/gtkutil.h | 3 +
src/xfns.c | 12 +++-
src/xterm.h | 4 ++
5 files changed, 220 insertions(+), 9 deletions(-)
diff --git a/src/frame.c b/src/frame.c
index 0a6ca26f5d..e4e430de8f 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -3550,6 +3550,7 @@ static const struct frame_parm_table frame_parms[] =
{"right-divider-width", SYMBOL_INDEX (Qright_divider_width)},
{"bottom-divider-width", SYMBOL_INDEX (Qbottom_divider_width)},
{"menu-bar-lines", SYMBOL_INDEX (Qmenu_bar_lines)},
+ {"menu-bar-scrollbar", SYMBOL_INDEX (Qmenu_bar_scrollbar)},
{"mouse-color", SYMBOL_INDEX (Qmouse_color)},
{"name", SYMBOL_INDEX (Qname)},
{"scroll-bar-width", SYMBOL_INDEX (Qscroll_bar_width)},
@@ -5660,6 +5661,11 @@ syms_of_frame (void)
DEFSYM (Qx_resource_name, "x-resource-name");
DEFSYM (Qx_frame_parameter, "x-frame-parameter");
+ /* Values for menu-bar-scrollbar frame parameter (GTK only) */
+ DEFSYM (Qautomatic, "automatic");
+ DEFSYM (Qalways, "always");
+ DEFSYM (Qforced_resize, "forced-resize");
+
DEFSYM (Qworkarea, "workarea");
DEFSYM (Qmm_size, "mm-size");
DEFSYM (Qframes, "frames");
@@ -5675,6 +5681,7 @@ syms_of_frame (void)
DEFSYM (Qtitle_bar_size, "title-bar-size");
DEFSYM (Qmenu_bar_external, "menu-bar-external");
DEFSYM (Qmenu_bar_size, "menu-bar-size");
+ DEFSYM (Qmenu_bar_scrollbar, "menu-bar-scrollbar");
DEFSYM (Qtool_bar_external, "tool-bar-external");
DEFSYM (Qtool_bar_size, "tool-bar-size");
/* The following are used for frame_size_history. */
diff --git a/src/gtkutil.c b/src/gtkutil.c
index 83b306a730..c4637e0cba 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -1136,6 +1136,10 @@ delete_cb (GtkWidget *widget,
return TRUE;
}
+#define MENUBAR_STYLESHEET \
+ ".mbtrunc * { border-width: 1px; margin-top: -2px; margin-bottom: -2px; }\n" \
+ ".mbscroll * { border-width: 1px; margin-top: -1px; margin-bottom: 0px; }\n"
+
/* Create and set up the GTK widgets for frame F.
Return true if creation succeeded. */
@@ -1147,6 +1151,9 @@ xg_create_frame_widgets (struct frame *f)
GtkWidget *wfixed;
#ifndef HAVE_GTK3
GtkRcStyle *style;
+#else
+ GtkCssProvider *css;
+ GdkScreen *screen;
#endif
char *title = 0;
@@ -1213,6 +1220,17 @@ xg_create_frame_widgets (struct frame *f)
store_frame_param (f, Qundecorated, Qt);
}
+ /* Add a CSS provider for the frame which will be used for dynamic styling
+ when we change widget behaviour (eg menubar scrollbars). */
+ css = gtk_css_provider_new ();
+ screen = gtk_widget_get_screen (wtop);
+ /* This should probably be moved ino the filesystem. */
+ gtk_css_provider_load_from_data (css, MENUBAR_STYLESHEET, -1, NULL);
+ gtk_style_context_add_provider_for_screen (screen,
+ GTK_STYLE_PROVIDER (css),
+ GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
+ g_object_unref (css);
+
FRAME_GTK_OUTER_WIDGET (f) = wtop;
FRAME_GTK_WIDGET (f) = wfixed;
f->output_data.x->vbox_widget = wvbox;
@@ -3434,7 +3452,11 @@ menubar_map_cb (GtkWidget *w, gpointer user_data)
{
GtkRequisition req;
struct frame *f = user_data;
- gtk_widget_get_preferred_size (w, NULL, &req);
+ struct x_output *x = f->output_data.x;
+
+ /* Use the menubar viewport for size if there is one: */
+ gtk_widget_get_preferred_size (x->menubar_visible_widget ?: w, NULL, &req);
+
if (FRAME_MENUBAR_HEIGHT (f) != req.height)
{
FRAME_MENUBAR_HEIGHT (f) = req.height;
@@ -3442,6 +3464,150 @@ menubar_map_cb (GtkWidget *w, gpointer user_data)
}
}
+/* Remove a gtk widget from any parent it may belong to.
+ Ensures that this does not change target's ref count. */
+static void
+orphan_widget (GtkWidget *w)
+{
+ GtkWidget *parent = gtk_widget_get_parent (w);
+
+ if (parent && GTK_IS_CONTAINER (parent))
+ {
+ g_object_ref (w);
+ gtk_container_remove (GTK_CONTAINER (parent), w);
+
+#if !GTK_CHECK_VERSION(3, 8, 0)
+ /* gtk 3.8 and earlier: viewport must be managed manually
+ but we don't need to save it, unlike the scrolled window
+ or the menubar. */
+ if (GTK_IS_VIEWPORT (parent))
+ {
+ GtkWidget *grandparent = gtk_widget_get_parent (parent);
+
+ if (parent && GTK_IS_CONTAINER (grandparent))
+ gtk_container_remove (GTK_CONTAINER (grandparent), parent);
+ }
+#endif
+ return;
+ }
+}
+
+/* As per orphan_widget but we also want to get rid of it and clean up. */
+static void
+discard_widget (GtkWidget *w)
+{
+ orphan_widget (w);
+ if (g_object_is_floating (w))
+ g_object_ref_sink (w);
+ g_object_unref (w);
+}
+
+/* Sets up the menubar style for scrolling/non-scrolling modes.
+ Reparents the menubar directly into the vbox for non-scrolling
+ mode and adds a scrolledwindow+viewport for scrolling modes. */
+static void
+menubar_scrollbox (struct frame *f, int scroll)
+{
+ struct x_output *x = f->output_data.x;
+
+ if (scroll)
+ {
+ if (x->menubar_visible_widget == x->menubar_viewport)
+ return;
+
+ x->menubar_visible_widget = x->menubar_viewport;
+ orphan_widget (x->menubar_widget);
+
+#if GTK_CHECK_VERSION (3, 8, 0)
+ gtk_container_add (GTK_CONTAINER (x->menubar_viewport), x->menubar_widget);
+#else
+ gtk_scrolled_window_add_with_viewport (GTK_SCROLLED_WINDOW (x->menubar_viewport), x->menubar_widget);
+#endif
+ }
+ else
+ {
+ if (x->menubar_visible_widget == x->menubar_widget)
+ return;
+
+ x->menubar_visible_widget = x->menubar_widget;
+ orphan_widget (x->menubar_widget);
+ orphan_widget (x->menubar_viewport);
+ }
+
+ gtk_box_pack_start (GTK_BOX (x->vbox_widget),
+ GTK_WIDGET (x->menubar_visible_widget), FALSE, FALSE, 0);
+ gtk_box_reorder_child (GTK_BOX (x->vbox_widget),
+ GTK_WIDGET (x->menubar_visible_widget), 0);
+ gtk_widget_show_all (x->menubar_visible_widget);
+}
+
+#if GTK_CHECK_VERSION (3, 16, 0)
+#define MENUBAR_SCROLLBAR_DEFAULT_POLICY GTK_POLICY_EXTERNAL
+#else
+#define MENUBAR_SCROLLBAR_DEFAULT_POLICY GTK_POLICY_NEVER
+#endif
+
+/* Apply the scrollbar mode and related style settings.
+ This also inserts or removes the intervening viewport as necessary
+ and maps any widgets that need mapping. Note that after gtk 3.16
+ we don't need (or want) to remove the scrolledwindow or viewport,
+ it suffices to change their style. */
+void
+xg_update_frame_menubar_scrollbar_mode (struct frame *f, Lisp_Object mode)
+{
+ GtkStyleContext *style;
+ struct x_output *x = f->output_data.x;
+ GtkScrolledWindow *sw;
+ GtkPolicyType scroll_policy = MENUBAR_SCROLLBAR_DEFAULT_POLICY;
+
+ if (!x->menubar_viewport)
+ return;
+
+ if (EQ (mode, Qautomatic))
+ scroll_policy = GTK_POLICY_AUTOMATIC;
+ else if (EQ (mode, Qalways))
+ scroll_policy = GTK_POLICY_ALWAYS;
+ else if (EQ (mode, Qforced_resize))
+ scroll_policy = GTK_POLICY_NEVER;
+
+ sw = GTK_SCROLLED_WINDOW (x->menubar_viewport);
+ style = gtk_widget_get_style_context (x->menubar_viewport);
+
+#if GTK_CHECK_VERSION(3, 16, 0)
+ /* Always want the scrollable container for capable-enough GTK versions */
+ menubar_scrollbox (f, 1);
+
+ switch (scroll_policy)
+ {
+ case GTK_POLICY_AUTOMATIC:
+ case GTK_POLICY_ALWAYS:
+ gtk_style_context_add_class (style, "mbscroll");
+ gtk_style_context_remove_class (style, "mbtrunc");
+ break;
+ default:
+ gtk_style_context_remove_class (style, "mbscroll");
+ gtk_style_context_add_class (style, "mbtrunc");
+ }
+#else
+ /* In older GTK versions we need to swap out the scrollable container
+ instead since we can't get truncating behaviour and CSS styling is
+ not well supported. */
+ switch (scroll_policy)
+ {
+ case GTK_POLICY_AUTOMATIC:
+ case GTK_POLICY_ALWAYS:
+ menubar_scrollbox (f, 1);
+ gtk_style_context_remove_class (style, "mbtrunc");
+ break;
+ default:
+ menubar_scrollbox (f, 0);
+ gtk_style_context_add_class (style, "mbtrunc");
+ }
+#endif
+
+ gtk_scrolled_window_set_policy (sw, scroll_policy, GTK_POLICY_AUTOMATIC);
+}
+
/* Recompute all the widgets of frame F, when the menu bar has been
changed. */
@@ -3450,6 +3616,7 @@ xg_update_frame_menubar (struct frame *f)
{
struct x_output *x = f->output_data.x;
GtkRequisition req;
+ Lisp_Object menuscroll;
if (!x->menubar_widget || gtk_widget_get_mapped (x->menubar_widget))
return;
@@ -3459,13 +3626,29 @@ xg_update_frame_menubar (struct frame *f)
block_input ();
- gtk_box_pack_start (GTK_BOX (x->vbox_widget), x->menubar_widget,
- FALSE, FALSE, 0);
- gtk_box_reorder_child (GTK_BOX (x->vbox_widget), x->menubar_widget, 0);
+ menuscroll = get_frame_param (f, Qmenu_bar_scrollbar);
+
+ /* Put the menu bar inside a scrolled window so that adding items
+ to the menu bar (such as when entering dired mode or activating
+ a minor more) does not trigger a frame resize:*/
+ x->menubar_viewport = gtk_scrolled_window_new(NULL, NULL);
+
+ /* Leave the keyboard focus where it is when clicking the scrollwindow: */
+#if GTK_CHECK_VERSION (3, 20, 0)
+ gtk_widget_set_focus_on_click (x->menubar_viewport, FALSE);
+#endif
+
+#if GTK_CHECK_VERSION (3, 16, 0)
+ /* If we don't set this then the scrollable keeps focus when the user
+ interacts with the scrollbar, at least until the menubar is clicked.
+ Overlay scrolling is more compact but until the focus problem is fixed
+ it's not livable with. */
+ gtk_scrolled_window_set_overlay_scrolling (GTK_SCROLLED_WINDOW (x->menubar_viewport), FALSE);
+#endif
g_signal_connect (x->menubar_widget, "map", G_CALLBACK (menubar_map_cb), f);
- gtk_widget_show_all (x->menubar_widget);
- gtk_widget_get_preferred_size (x->menubar_widget, NULL, &req);
+ xg_update_frame_menubar_scrollbar_mode (f, menuscroll);
+ gtk_widget_get_preferred_size (x->menubar_visible_widget, NULL, &req);
if (FRAME_MENUBAR_HEIGHT (f) != req.height)
{
@@ -3487,10 +3670,14 @@ free_frame_menubar (struct frame *f)
{
block_input ();
- gtk_container_remove (GTK_CONTAINER (x->vbox_widget), x->menubar_widget);
+ discard_widget (x->menubar_widget);
+ discard_widget (x->menubar_viewport);
+
/* The menubar and its children shall be deleted when removed from
the container. */
- x->menubar_widget = 0;
+ x->menubar_visible_widget = NULL;
+ x->menubar_viewport = NULL;
+ x->menubar_widget = NULL;
FRAME_MENUBAR_HEIGHT (f) = 0;
adjust_frame_size (f, -1, -1, 2, 0, Qmenu_bar_lines);
unblock_input ();
diff --git a/src/gtkutil.h b/src/gtkutil.h
index 7dcd549f5c..96220f27c8 100644
--- a/src/gtkutil.h
+++ b/src/gtkutil.h
@@ -103,6 +103,9 @@ extern void xg_modify_menubar_widgets (GtkWidget *menubar,
GCallback deactivate_cb,
GCallback highlight_cb);
+extern void xg_update_frame_menubar_scrollbar_mode (struct frame *f,
+ Lisp_Object mode);
+
extern void xg_update_frame_menubar (struct frame *f);
extern bool xg_event_is_for_menubar (struct frame *, const XEvent *);
diff --git a/src/xfns.c b/src/xfns.c
index 3da853ede8..9503ae1e1d 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -1601,6 +1601,13 @@ x_set_menu_bar_lines (struct frame *f, Lisp_Object value, Lisp_Object oldval)
adjust_frame_glyphs (f);
}
+static void
+x_set_menu_bar_scrollbar (struct frame *f, Lisp_Object value, Lisp_Object oldval)
+{
+#ifdef USE_GTK /* menubar resize/scrolling only happens under GTK. */
+ xg_update_frame_menubar_scrollbar_mode (f, value);
+#endif
+}
/* Set the number of lines used for the tool bar of frame F to VALUE.
VALUE not an integer, or < 0 means set the lines to zero. OLDVAL
@@ -3888,7 +3895,9 @@ This function is an internal primitive--use `make-frame' instead. */)
NILP (Vtool_bar_mode)
? make_number (0) : make_number (1),
NULL, NULL, RES_TYPE_NUMBER);
-
+ /* How scrolling is handled for oversized (too wide) menu bars. */
+ x_default_parameter (f, parms, Qmenu_bar_scrollbar, Qnil,
+ NULL, NULL, RES_TYPE_SYMBOL);
x_default_parameter (f, parms, Qbuffer_predicate, Qnil,
"bufferPredicate", "BufferPredicate",
RES_TYPE_SYMBOL);
@@ -7536,6 +7545,7 @@ frame_parm_handler x_frame_parm_handlers[] =
x_set_right_divider_width,
x_set_bottom_divider_width,
x_set_menu_bar_lines,
+ x_set_menu_bar_scrollbar,
x_set_mouse_color,
x_explicitly_set_name,
x_set_scroll_bar_width,
diff --git a/src/xterm.h b/src/xterm.h
index f73dd0e25a..ac5f7f08da 100644
--- a/src/xterm.h
+++ b/src/xterm.h
@@ -581,7 +581,11 @@ struct x_output
/* The widget used for laying out widgets horizontally. */
GtkWidget *hbox_widget;
/* The menubar in this frame. */
+ GtkWidget *menubar_viewport;
GtkWidget *menubar_widget;
+ /* If the viewport is in usem this will be the viewport, otherwise it
+ will be the menubar_widget. Used to get height calculations right. */
+ GtkWidget *menubar_visible_widget;
/* The tool bar in this frame */
GtkWidget *toolbar_widget;
/* True if tool bar is packed into the hbox widget (i.e. vertical). */
--
2.11.0
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: Type: TEXT/x-diff; name=0002-Document-the-new-menu-bar-scrollbar-frame-parameter.patch, Size: 2022 bytes --]
From 489a38cceda02e62dc50367347930713f4454f95 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vivek=20Das=C2=A0Mohapatra?= <vivek@collabora.com>
Date: Thu, 11 Oct 2018 13:48:47 +0100
Subject: [PATCH 2/3] Document the new menu-bar-scrollbar frame parameter
---
doc/lispref/frames.texi | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/doc/lispref/frames.texi b/doc/lispref/frames.texi
index 2f9bb39886..601749d97e 100644
--- a/doc/lispref/frames.texi
+++ b/doc/lispref/frames.texi
@@ -601,6 +601,10 @@ Frame Layout
frame unchanged, so the native height of the frame (see below) will
change instead.
+If the menu bar is drawn by GTK then its behavior when it would grow
+wider than the root frame is controlled by the @code{menu-bar-scrollbar}
+parameter (@pxref{Layout Parameters}).
+
@item Tool Bar
@cindex internal tool bar
@cindex external tool bar
@@ -1814,6 +1818,23 @@ Layout Parameters
(@pxref{Frame Geometry}) allows to derive whether the menu bar actually
occupies one or more lines.
+@vindex menu-bar-scrollbar@r{, a frame parameter}
+@item menu-bar-scrollbar
+The behavior of GTK menu bars when they would otherwise grow wider than
+the frame. Valid values are:
+@itemize
+@item @code{always} - Scrollbar is present, menu bar scrolls when too wide.
+@item @code{automatic} - Scrollbar appears when menubar grows too wide.
+@item @code{forced-resize} - No scrollbar. Growing menubar forces a frame resize.
+@item @code{nil} (or any other value)
+@itemize
+@item GTK >= 3.16 - No scrollbar. Menu bar is truncated if it grows too wide.
+@item GTK < 3,16 - Same behavior as @code{forced-resize}.
+@end itemize
+@end itemize
+It is worth noting that for GTK before 3.16 the scrollbar adds a significant
+amount of vertical padding to the menubar: This appears to be unavoidable.
+
@vindex tool-bar-lines@r{, a frame parameter}
@item tool-bar-lines
The number of lines to use for the tool bar (@pxref{Tool Bar}). The
--
2.11.0
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: Type: TEXT/x-diff; name=0003-Hook-up-menu-bar-scrollbar-functionality-to-customiz.patch, Size: 8879 bytes --]
From d281f45206321ef7e41e73baa0edf67f0e7216be Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vivek=20Das=C2=A0Mohapatra?= <vivek@collabora.com>
Date: Thu, 18 Oct 2018 01:38:05 +0100
Subject: [PATCH 3/3] Hook up menu bar scrollbar functionality to customize &
Options menu
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
menu-bar-scrollbar-mode custom variable updates default and
initial frame parameters.
menu-bar-scrollbar-mode command cycles the custom variable through
the available/supported values
Options ► Show Hide ► Menu Bar Scroll/Truncate menu connected to
the custom variable.
---
| 137 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 137 insertions(+)
--git a/lisp/menu-bar.el b/lisp/menu-bar.el
index e2ebd98119..e8b36851e2 100644
--- a/lisp/menu-bar.el
+++ b/lisp/menu-bar.el
@@ -673,6 +673,7 @@ menu-bar-options-save
line-number-mode column-number-mode size-indication-mode
cua-mode show-paren-mode transient-mark-mode
blink-cursor-mode display-time-mode display-battery-mode
+ menu-bar-scrollbar-mode
;; These are set by other functions that don't set
;; the customized state. Having them here has the
;; side-effect that turning them off via X
@@ -1042,6 +1043,137 @@ menu-bar-showhide-tool-bar-menu-customize-enable-bottom
(interactive)
(menu-bar-set-tool-bar-position 'bottom))
+(defcustom menu-bar-scrollbar-mode nil
+ "Specify how GTK menu bars deal with the frame being too narrow to hold them.\n
+Valid values are:
+ `always' - the menu bar always has a scrollbar
+ `automatic' - a scrollbar is added when required
+ `forced-resize' - no scrollbar, the frame is forced to resize to accommodate
+ the menu bar.
+ nil (or any other value) - the menu bar is truncated\n
+Note that prior to GTK 3.16 truncation is not possible and the default
+is equivalent to 'forced-resize.\n
+Do not set this variable directly - use the customize interface to make sure
+that `default-frame-alist', `initial-frame-alist' and all existing frames
+remain in sync."
+ :version "26.1"
+ :type '(choice (const always)
+ (const automaic)
+ (const forced-resize)
+ (const nil))
+ :group 'frames
+ :initialize 'custom-initialize-default
+ :set (lambda (sym val)
+ (setq val (if (memq val '(automatic always forced-resize)) val nil))
+ (set-default sym val)
+ (modify-all-frames-parameters
+ (list (cons 'menu-bar-scrollbar val)))))
+
+(defun menu-bar-can-be-truncated ()
+ (let (version)
+ (when (boundp 'gtk-version-string)
+ (setq version (mapcar 'string-to-number (split-string gtk-version-string "\\.")))
+ (or (and (eq (car version) 3) (>= (cadr version) 16))
+ (>= (car version) 4)))))
+
+(defun menu-bar-scrollbar-next-mode (mode)
+ "Return the next menu-bar-scrollbar frame parameter value after MODE.
+Takes into account the abilities of the available GTK version."
+ (if (menu-bar-can-be-truncated)
+ (progn
+ (if (not (memq mode '(always automatic forced-resize nil))) (setq mode nil))
+ (cadr (memq mode '(nil automatic always forced-resize nil))))
+ (if (not (memq mode '(always automatic nil))) (setq mode nil))
+ (cadr (memq mode '(nil automatic always nil)))))
+
+(defun menu-bar-scrollbar-mode (&optional mode)
+ "Cycle through scroll/truncate/resize modes for GTK menu bars.\n
+If the optional parameter MODE is specified then apply that instead.
+The new mode is stored in the variable `menu-bar-scrollbar-mode' via
+the custom interface (but not automatically saved).\n
+Returns the new MODE.\n
+NOTE: pass 'default if you want to set the mode explicitly to nil.\n
+See `menu-bar-scrollbar' in Info node `(elisp)Layout Parameters' for details."
+ (interactive)
+ (if mode
+ ;; explicit mode passed, map any non-standard value back to nil
+ (setq mode (car (memq mode '(automatic always forced-resize))))
+ ;; no explicit mode: pick the new value based on our fixed progression:
+ (setq mode (menu-bar-scrollbar-next-mode
+ (or menu-bar-scrollbar-mode 'default))))
+ ;; set, apply but do not save the new value:
+ (customize-set-variable 'menu-bar-scrollbar-mode mode)
+ mode)
+
+(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-forced-resize ()
+ "Resize the frame to accommodate the menu bar."
+ (interactive)
+ (customize-set-variable 'menu-bar-scrollbar-mode 'forced-resize))
+(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-always ()
+ "Add a permanent scrollbar to the menu bar."
+ (interactive)
+ (customize-set-variable 'menu-bar-scrollbar-mode 'always))
+(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-automatic ()
+ "Add a scrollbar to the menu bar when it tries to grow past the frame edge.."
+ (interactive)
+ (customize-set-variable 'menu-bar-scrollbar-mode 'automatic))
+(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-nil ()
+ "Truncate the menu bar to fit the frame."
+ (interactive)
+ (customize-set-variable 'menu-bar-scrollbar-mode 'default))
+
+(defvar menu-bar-showhide-menu-bar-scrollbar-mode-menu
+ (let ((menu (make-sparse-keymap "Menu Bar Scroll/Truncate")))
+
+ (bindings--define-key menu [showhide-menu-bar-scrollbar-mode-forced-resize]
+ '(menu-item "Resize Frame"
+ menu-bar-showhide-menu-bar-scrollbar-mode-customize-forced-resize
+ :help "Resize the frame to accommodate the menu bar"
+ :visible (display-graphic-p)
+ :button
+ (:radio . (if (menu-bar-can-be-truncated)
+ (eq (frame-parameter
+ (menu-bar-frame-for-menubar)
+ 'menu-bar-scrollbar)
+ 'forced-resize)
+ (not (memq (frame-parameter
+ (menu-bar-frame-for-menubar)
+ 'menu-bar-scrollbar)
+ '(automatic always)))))))
+
+ (bindings--define-key menu [showhide-menu-bar-scrollbar-mode-always]
+ '(menu-item "Always Scroll"
+ menu-bar-showhide-menu-bar-scrollbar-mode-customize-always
+ :help "Always add a scroll bar to the menu bar"
+ :visible (display-graphic-p)
+ :button
+ (:radio . (eq (frame-parameter (menu-bar-frame-for-menubar)
+ 'menu-bar-scrollbar)
+ 'always))))
+
+ (bindings--define-key menu [showhide-menu-bar-scrollbar-mode-automatic]
+ '(menu-item "Automatic"
+ menu-bar-showhide-menu-bar-scrollbar-mode-customize-automatic
+ :help "Display a scroll bar only when the menu is too wide"
+ :visible (display-graphic-p)
+ :button
+ (:radio . (eq (frame-parameter (menu-bar-frame-for-menubar)
+ 'menu-bar-scrollbar)
+ 'automatic))))
+
+ (bindings--define-key menu [showhide-menu-bar-scrollbar-mode-truncate]
+ '(menu-item "Truncate"
+ menu-bar-showhide-menu-bar-scrollbar-mode-customize-nil
+ :help "Truncate the menubar to fit inside the frame"
+ :visible (and (display-graphic-p)
+ (menu-bar-can-be-truncated))
+ :button
+ (:radio . (not (memq
+ (frame-parameter (menu-bar-frame-for-menubar)
+ 'menu-bar-scrollbar)
+ '(automatic always forced-resize))))))
+ menu))
+
(when (featurep 'move-toolbar)
(defvar menu-bar-showhide-tool-bar-menu
(let ((menu (make-sparse-keymap "Tool Bar")))
@@ -1225,6 +1357,11 @@ menu-bar-showhide-menu
:visible (and (display-graphic-p) (fboundp 'x-show-tip))
:button (:toggle . tooltip-mode)))
+ (bindings--define-key menu [showhide-menu-bar-scrollbar-menu]
+ `(menu-item "Menu Bar Scroll/Truncate"
+ ,menu-bar-showhide-menu-bar-scrollbar-mode-menu
+ :visible (display-graphic-p)))
+
(bindings--define-key menu [menu-bar-mode]
'(menu-item "Menu Bar" toggle-menu-bar-mode-from-frame
:help "Turn menu bar on/off"
--
2.11.0
^ permalink raw reply related [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 1:02 ` Vivek Dasmohapatra
@ 2018-10-18 8:06 ` martin rudalics
2018-10-18 12:23 ` Vivek Dasmohapatra
2018-10-18 13:34 ` Eli Zaretskii
0 siblings, 2 replies; 97+ messages in thread
From: martin rudalics @ 2018-10-18 8:06 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: 22000, David Engster
> New patch series - I think this has all the features and functionality
> discussed so far.
Everything's alright with two nitpicks:
(1) The version tag of 'menu-bar-scrollbar-mode' must be 26.2 unless Eli
decides that this may go to master only.
(2) Please make the 'showhide-menu-bar-scrollbar-menu' dependent on
whether GTK is used. Something like
(when (featurep 'gtk)
(defvar menu-bar-showhide-menu-bar-scrollbar-mode-menu
and
(when (featurep 'gtk)
(bindings--define-key menu [showhide-menu-bar-scrollbar-menu]
Eli, I think this should go to the release branch. If it introduces any
problems, we should find out soon enough - I think that most of our GTK
users leave the menu bar on. But it is not just a cosmetic change. It
would have helped if anyone else tested this but unfortunately this was
not the case.
martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 8:06 ` martin rudalics
@ 2018-10-18 12:23 ` Vivek Dasmohapatra
2018-10-18 12:48 ` Robert Pluim
2018-10-18 13:51 ` Eli Zaretskii
2018-10-18 13:34 ` Eli Zaretskii
1 sibling, 2 replies; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-18 12:23 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, David Engster
[-- Attachment #1: Type: TEXT/PLAIN, Size: 63 bytes --]
featurep guards added, defcustom setting emacs version bumped.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: TEXT/x-diff; name=0001-GTK3-menu-bars-force-frame-resizing-Bug-22000.patch, Size: 16011 bytes --]
From c9e24d6bf4d3d5baae9bb4dade97cfcb8a5ecafc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vivek=20Das=C2=A0Mohapatra?= <vivek@collabora.com>
Date: Sun, 15 Jul 2018 18:59:59 +0100
Subject: [PATCH 1/3] GTK3 menu bars force frame resizing (Bug#22000)
Menu bars force the frame they are in to resize when the menu bar
width exceeds the frame width, both at the point the menu bar grows
past the frame width and whenever the gtk idle resize callback is
triggered.
The effect is that the user's frame width is effectively ignored, and
emacs will semi-predictably resize itself to accommodate the menu bar.
This effect can be suppressed by wrapping the menu bar in a scrollable
window.
This behaviour is controlled by the `menu-bar-scrollbar' parameter
which may have a value of 'automatic, 'always, 'forced-resize or
anything else (equivalent to nil).
Limitations in earlier versions of GTK mean that there are
some version-dependent differences in behaviour.
GTK 3.16 and later:
The menu bar is always in a scrolled window . In the default mode
the menu bar is truncated when it tries to grow wider than the frame.
CSS is used to strip away the excess space this introduces.
In 'always or 'automatic mode, the CSS is relaxed slightly to work
around a GTK focus glitch, but otherwise the widget setup is identical.
The menubar will have a scrollbar either always, or when it tries to
grow too wide.
In 'forced-resize mode the frame-size-jitter behaviour described in
bug #22000 is preserved.
Before GTK 3.16:
When in 'always or 'automatic mode, the menu bar will be in a scrolled
window. The extra space cannot be properly ameliorated with CSS
styling as this does not seem to work well.
In the default mode, the scrolled window is not present - the menu bar
is dynamically re-parented between the scrolled window (which is
created on demand) and the emacs pane (vbox widget) when the menu bar
scrolling mode is changed.
In these versions of GTK the menu-bar truncation behaviour is not
easily achievable, so the default mode is identical to 'forced-resize
mode.
---
src/frame.c | 7 ++
src/gtkutil.c | 203 +++++++++++++++++++++++++++++++++++++++++++++++++++++++---
src/gtkutil.h | 3 +
src/xfns.c | 12 +++-
src/xterm.h | 4 ++
5 files changed, 220 insertions(+), 9 deletions(-)
diff --git a/src/frame.c b/src/frame.c
index 0a6ca26f5d..e4e430de8f 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -3550,6 +3550,7 @@ static const struct frame_parm_table frame_parms[] =
{"right-divider-width", SYMBOL_INDEX (Qright_divider_width)},
{"bottom-divider-width", SYMBOL_INDEX (Qbottom_divider_width)},
{"menu-bar-lines", SYMBOL_INDEX (Qmenu_bar_lines)},
+ {"menu-bar-scrollbar", SYMBOL_INDEX (Qmenu_bar_scrollbar)},
{"mouse-color", SYMBOL_INDEX (Qmouse_color)},
{"name", SYMBOL_INDEX (Qname)},
{"scroll-bar-width", SYMBOL_INDEX (Qscroll_bar_width)},
@@ -5660,6 +5661,11 @@ syms_of_frame (void)
DEFSYM (Qx_resource_name, "x-resource-name");
DEFSYM (Qx_frame_parameter, "x-frame-parameter");
+ /* Values for menu-bar-scrollbar frame parameter (GTK only) */
+ DEFSYM (Qautomatic, "automatic");
+ DEFSYM (Qalways, "always");
+ DEFSYM (Qforced_resize, "forced-resize");
+
DEFSYM (Qworkarea, "workarea");
DEFSYM (Qmm_size, "mm-size");
DEFSYM (Qframes, "frames");
@@ -5675,6 +5681,7 @@ syms_of_frame (void)
DEFSYM (Qtitle_bar_size, "title-bar-size");
DEFSYM (Qmenu_bar_external, "menu-bar-external");
DEFSYM (Qmenu_bar_size, "menu-bar-size");
+ DEFSYM (Qmenu_bar_scrollbar, "menu-bar-scrollbar");
DEFSYM (Qtool_bar_external, "tool-bar-external");
DEFSYM (Qtool_bar_size, "tool-bar-size");
/* The following are used for frame_size_history. */
diff --git a/src/gtkutil.c b/src/gtkutil.c
index 83b306a730..c4637e0cba 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -1136,6 +1136,10 @@ delete_cb (GtkWidget *widget,
return TRUE;
}
+#define MENUBAR_STYLESHEET \
+ ".mbtrunc * { border-width: 1px; margin-top: -2px; margin-bottom: -2px; }\n" \
+ ".mbscroll * { border-width: 1px; margin-top: -1px; margin-bottom: 0px; }\n"
+
/* Create and set up the GTK widgets for frame F.
Return true if creation succeeded. */
@@ -1147,6 +1151,9 @@ xg_create_frame_widgets (struct frame *f)
GtkWidget *wfixed;
#ifndef HAVE_GTK3
GtkRcStyle *style;
+#else
+ GtkCssProvider *css;
+ GdkScreen *screen;
#endif
char *title = 0;
@@ -1213,6 +1220,17 @@ xg_create_frame_widgets (struct frame *f)
store_frame_param (f, Qundecorated, Qt);
}
+ /* Add a CSS provider for the frame which will be used for dynamic styling
+ when we change widget behaviour (eg menubar scrollbars). */
+ css = gtk_css_provider_new ();
+ screen = gtk_widget_get_screen (wtop);
+ /* This should probably be moved ino the filesystem. */
+ gtk_css_provider_load_from_data (css, MENUBAR_STYLESHEET, -1, NULL);
+ gtk_style_context_add_provider_for_screen (screen,
+ GTK_STYLE_PROVIDER (css),
+ GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
+ g_object_unref (css);
+
FRAME_GTK_OUTER_WIDGET (f) = wtop;
FRAME_GTK_WIDGET (f) = wfixed;
f->output_data.x->vbox_widget = wvbox;
@@ -3434,7 +3452,11 @@ menubar_map_cb (GtkWidget *w, gpointer user_data)
{
GtkRequisition req;
struct frame *f = user_data;
- gtk_widget_get_preferred_size (w, NULL, &req);
+ struct x_output *x = f->output_data.x;
+
+ /* Use the menubar viewport for size if there is one: */
+ gtk_widget_get_preferred_size (x->menubar_visible_widget ?: w, NULL, &req);
+
if (FRAME_MENUBAR_HEIGHT (f) != req.height)
{
FRAME_MENUBAR_HEIGHT (f) = req.height;
@@ -3442,6 +3464,150 @@ menubar_map_cb (GtkWidget *w, gpointer user_data)
}
}
+/* Remove a gtk widget from any parent it may belong to.
+ Ensures that this does not change target's ref count. */
+static void
+orphan_widget (GtkWidget *w)
+{
+ GtkWidget *parent = gtk_widget_get_parent (w);
+
+ if (parent && GTK_IS_CONTAINER (parent))
+ {
+ g_object_ref (w);
+ gtk_container_remove (GTK_CONTAINER (parent), w);
+
+#if !GTK_CHECK_VERSION(3, 8, 0)
+ /* gtk 3.8 and earlier: viewport must be managed manually
+ but we don't need to save it, unlike the scrolled window
+ or the menubar. */
+ if (GTK_IS_VIEWPORT (parent))
+ {
+ GtkWidget *grandparent = gtk_widget_get_parent (parent);
+
+ if (parent && GTK_IS_CONTAINER (grandparent))
+ gtk_container_remove (GTK_CONTAINER (grandparent), parent);
+ }
+#endif
+ return;
+ }
+}
+
+/* As per orphan_widget but we also want to get rid of it and clean up. */
+static void
+discard_widget (GtkWidget *w)
+{
+ orphan_widget (w);
+ if (g_object_is_floating (w))
+ g_object_ref_sink (w);
+ g_object_unref (w);
+}
+
+/* Sets up the menubar style for scrolling/non-scrolling modes.
+ Reparents the menubar directly into the vbox for non-scrolling
+ mode and adds a scrolledwindow+viewport for scrolling modes. */
+static void
+menubar_scrollbox (struct frame *f, int scroll)
+{
+ struct x_output *x = f->output_data.x;
+
+ if (scroll)
+ {
+ if (x->menubar_visible_widget == x->menubar_viewport)
+ return;
+
+ x->menubar_visible_widget = x->menubar_viewport;
+ orphan_widget (x->menubar_widget);
+
+#if GTK_CHECK_VERSION (3, 8, 0)
+ gtk_container_add (GTK_CONTAINER (x->menubar_viewport), x->menubar_widget);
+#else
+ gtk_scrolled_window_add_with_viewport (GTK_SCROLLED_WINDOW (x->menubar_viewport), x->menubar_widget);
+#endif
+ }
+ else
+ {
+ if (x->menubar_visible_widget == x->menubar_widget)
+ return;
+
+ x->menubar_visible_widget = x->menubar_widget;
+ orphan_widget (x->menubar_widget);
+ orphan_widget (x->menubar_viewport);
+ }
+
+ gtk_box_pack_start (GTK_BOX (x->vbox_widget),
+ GTK_WIDGET (x->menubar_visible_widget), FALSE, FALSE, 0);
+ gtk_box_reorder_child (GTK_BOX (x->vbox_widget),
+ GTK_WIDGET (x->menubar_visible_widget), 0);
+ gtk_widget_show_all (x->menubar_visible_widget);
+}
+
+#if GTK_CHECK_VERSION (3, 16, 0)
+#define MENUBAR_SCROLLBAR_DEFAULT_POLICY GTK_POLICY_EXTERNAL
+#else
+#define MENUBAR_SCROLLBAR_DEFAULT_POLICY GTK_POLICY_NEVER
+#endif
+
+/* Apply the scrollbar mode and related style settings.
+ This also inserts or removes the intervening viewport as necessary
+ and maps any widgets that need mapping. Note that after gtk 3.16
+ we don't need (or want) to remove the scrolledwindow or viewport,
+ it suffices to change their style. */
+void
+xg_update_frame_menubar_scrollbar_mode (struct frame *f, Lisp_Object mode)
+{
+ GtkStyleContext *style;
+ struct x_output *x = f->output_data.x;
+ GtkScrolledWindow *sw;
+ GtkPolicyType scroll_policy = MENUBAR_SCROLLBAR_DEFAULT_POLICY;
+
+ if (!x->menubar_viewport)
+ return;
+
+ if (EQ (mode, Qautomatic))
+ scroll_policy = GTK_POLICY_AUTOMATIC;
+ else if (EQ (mode, Qalways))
+ scroll_policy = GTK_POLICY_ALWAYS;
+ else if (EQ (mode, Qforced_resize))
+ scroll_policy = GTK_POLICY_NEVER;
+
+ sw = GTK_SCROLLED_WINDOW (x->menubar_viewport);
+ style = gtk_widget_get_style_context (x->menubar_viewport);
+
+#if GTK_CHECK_VERSION(3, 16, 0)
+ /* Always want the scrollable container for capable-enough GTK versions */
+ menubar_scrollbox (f, 1);
+
+ switch (scroll_policy)
+ {
+ case GTK_POLICY_AUTOMATIC:
+ case GTK_POLICY_ALWAYS:
+ gtk_style_context_add_class (style, "mbscroll");
+ gtk_style_context_remove_class (style, "mbtrunc");
+ break;
+ default:
+ gtk_style_context_remove_class (style, "mbscroll");
+ gtk_style_context_add_class (style, "mbtrunc");
+ }
+#else
+ /* In older GTK versions we need to swap out the scrollable container
+ instead since we can't get truncating behaviour and CSS styling is
+ not well supported. */
+ switch (scroll_policy)
+ {
+ case GTK_POLICY_AUTOMATIC:
+ case GTK_POLICY_ALWAYS:
+ menubar_scrollbox (f, 1);
+ gtk_style_context_remove_class (style, "mbtrunc");
+ break;
+ default:
+ menubar_scrollbox (f, 0);
+ gtk_style_context_add_class (style, "mbtrunc");
+ }
+#endif
+
+ gtk_scrolled_window_set_policy (sw, scroll_policy, GTK_POLICY_AUTOMATIC);
+}
+
/* Recompute all the widgets of frame F, when the menu bar has been
changed. */
@@ -3450,6 +3616,7 @@ xg_update_frame_menubar (struct frame *f)
{
struct x_output *x = f->output_data.x;
GtkRequisition req;
+ Lisp_Object menuscroll;
if (!x->menubar_widget || gtk_widget_get_mapped (x->menubar_widget))
return;
@@ -3459,13 +3626,29 @@ xg_update_frame_menubar (struct frame *f)
block_input ();
- gtk_box_pack_start (GTK_BOX (x->vbox_widget), x->menubar_widget,
- FALSE, FALSE, 0);
- gtk_box_reorder_child (GTK_BOX (x->vbox_widget), x->menubar_widget, 0);
+ menuscroll = get_frame_param (f, Qmenu_bar_scrollbar);
+
+ /* Put the menu bar inside a scrolled window so that adding items
+ to the menu bar (such as when entering dired mode or activating
+ a minor more) does not trigger a frame resize:*/
+ x->menubar_viewport = gtk_scrolled_window_new(NULL, NULL);
+
+ /* Leave the keyboard focus where it is when clicking the scrollwindow: */
+#if GTK_CHECK_VERSION (3, 20, 0)
+ gtk_widget_set_focus_on_click (x->menubar_viewport, FALSE);
+#endif
+
+#if GTK_CHECK_VERSION (3, 16, 0)
+ /* If we don't set this then the scrollable keeps focus when the user
+ interacts with the scrollbar, at least until the menubar is clicked.
+ Overlay scrolling is more compact but until the focus problem is fixed
+ it's not livable with. */
+ gtk_scrolled_window_set_overlay_scrolling (GTK_SCROLLED_WINDOW (x->menubar_viewport), FALSE);
+#endif
g_signal_connect (x->menubar_widget, "map", G_CALLBACK (menubar_map_cb), f);
- gtk_widget_show_all (x->menubar_widget);
- gtk_widget_get_preferred_size (x->menubar_widget, NULL, &req);
+ xg_update_frame_menubar_scrollbar_mode (f, menuscroll);
+ gtk_widget_get_preferred_size (x->menubar_visible_widget, NULL, &req);
if (FRAME_MENUBAR_HEIGHT (f) != req.height)
{
@@ -3487,10 +3670,14 @@ free_frame_menubar (struct frame *f)
{
block_input ();
- gtk_container_remove (GTK_CONTAINER (x->vbox_widget), x->menubar_widget);
+ discard_widget (x->menubar_widget);
+ discard_widget (x->menubar_viewport);
+
/* The menubar and its children shall be deleted when removed from
the container. */
- x->menubar_widget = 0;
+ x->menubar_visible_widget = NULL;
+ x->menubar_viewport = NULL;
+ x->menubar_widget = NULL;
FRAME_MENUBAR_HEIGHT (f) = 0;
adjust_frame_size (f, -1, -1, 2, 0, Qmenu_bar_lines);
unblock_input ();
diff --git a/src/gtkutil.h b/src/gtkutil.h
index 7dcd549f5c..96220f27c8 100644
--- a/src/gtkutil.h
+++ b/src/gtkutil.h
@@ -103,6 +103,9 @@ extern void xg_modify_menubar_widgets (GtkWidget *menubar,
GCallback deactivate_cb,
GCallback highlight_cb);
+extern void xg_update_frame_menubar_scrollbar_mode (struct frame *f,
+ Lisp_Object mode);
+
extern void xg_update_frame_menubar (struct frame *f);
extern bool xg_event_is_for_menubar (struct frame *, const XEvent *);
diff --git a/src/xfns.c b/src/xfns.c
index 3da853ede8..9503ae1e1d 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -1601,6 +1601,13 @@ x_set_menu_bar_lines (struct frame *f, Lisp_Object value, Lisp_Object oldval)
adjust_frame_glyphs (f);
}
+static void
+x_set_menu_bar_scrollbar (struct frame *f, Lisp_Object value, Lisp_Object oldval)
+{
+#ifdef USE_GTK /* menubar resize/scrolling only happens under GTK. */
+ xg_update_frame_menubar_scrollbar_mode (f, value);
+#endif
+}
/* Set the number of lines used for the tool bar of frame F to VALUE.
VALUE not an integer, or < 0 means set the lines to zero. OLDVAL
@@ -3888,7 +3895,9 @@ This function is an internal primitive--use `make-frame' instead. */)
NILP (Vtool_bar_mode)
? make_number (0) : make_number (1),
NULL, NULL, RES_TYPE_NUMBER);
-
+ /* How scrolling is handled for oversized (too wide) menu bars. */
+ x_default_parameter (f, parms, Qmenu_bar_scrollbar, Qnil,
+ NULL, NULL, RES_TYPE_SYMBOL);
x_default_parameter (f, parms, Qbuffer_predicate, Qnil,
"bufferPredicate", "BufferPredicate",
RES_TYPE_SYMBOL);
@@ -7536,6 +7545,7 @@ frame_parm_handler x_frame_parm_handlers[] =
x_set_right_divider_width,
x_set_bottom_divider_width,
x_set_menu_bar_lines,
+ x_set_menu_bar_scrollbar,
x_set_mouse_color,
x_explicitly_set_name,
x_set_scroll_bar_width,
diff --git a/src/xterm.h b/src/xterm.h
index f73dd0e25a..ac5f7f08da 100644
--- a/src/xterm.h
+++ b/src/xterm.h
@@ -581,7 +581,11 @@ struct x_output
/* The widget used for laying out widgets horizontally. */
GtkWidget *hbox_widget;
/* The menubar in this frame. */
+ GtkWidget *menubar_viewport;
GtkWidget *menubar_widget;
+ /* If the viewport is in usem this will be the viewport, otherwise it
+ will be the menubar_widget. Used to get height calculations right. */
+ GtkWidget *menubar_visible_widget;
/* The tool bar in this frame */
GtkWidget *toolbar_widget;
/* True if tool bar is packed into the hbox widget (i.e. vertical). */
--
2.11.0
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: Type: TEXT/x-diff; name=0002-Document-the-new-menu-bar-scrollbar-frame-parameter.patch, Size: 2022 bytes --]
From 489a38cceda02e62dc50367347930713f4454f95 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vivek=20Das=C2=A0Mohapatra?= <vivek@collabora.com>
Date: Thu, 11 Oct 2018 13:48:47 +0100
Subject: [PATCH 2/3] Document the new menu-bar-scrollbar frame parameter
---
doc/lispref/frames.texi | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/doc/lispref/frames.texi b/doc/lispref/frames.texi
index 2f9bb39886..601749d97e 100644
--- a/doc/lispref/frames.texi
+++ b/doc/lispref/frames.texi
@@ -601,6 +601,10 @@ Frame Layout
frame unchanged, so the native height of the frame (see below) will
change instead.
+If the menu bar is drawn by GTK then its behavior when it would grow
+wider than the root frame is controlled by the @code{menu-bar-scrollbar}
+parameter (@pxref{Layout Parameters}).
+
@item Tool Bar
@cindex internal tool bar
@cindex external tool bar
@@ -1814,6 +1818,23 @@ Layout Parameters
(@pxref{Frame Geometry}) allows to derive whether the menu bar actually
occupies one or more lines.
+@vindex menu-bar-scrollbar@r{, a frame parameter}
+@item menu-bar-scrollbar
+The behavior of GTK menu bars when they would otherwise grow wider than
+the frame. Valid values are:
+@itemize
+@item @code{always} - Scrollbar is present, menu bar scrolls when too wide.
+@item @code{automatic} - Scrollbar appears when menubar grows too wide.
+@item @code{forced-resize} - No scrollbar. Growing menubar forces a frame resize.
+@item @code{nil} (or any other value)
+@itemize
+@item GTK >= 3.16 - No scrollbar. Menu bar is truncated if it grows too wide.
+@item GTK < 3,16 - Same behavior as @code{forced-resize}.
+@end itemize
+@end itemize
+It is worth noting that for GTK before 3.16 the scrollbar adds a significant
+amount of vertical padding to the menubar: This appears to be unavoidable.
+
@vindex tool-bar-lines@r{, a frame parameter}
@item tool-bar-lines
The number of lines to use for the tool bar (@pxref{Tool Bar}). The
--
2.11.0
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: Type: TEXT/x-diff; name=0003-Hook-up-menu-bar-scrollbar-functionality-to-customiz.patch, Size: 9030 bytes --]
From 31e687a7c848bbc4e0a7ef34acc4f55a7d5a9004 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vivek=20Das=C2=A0Mohapatra?= <vivek@collabora.com>
Date: Thu, 18 Oct 2018 01:38:05 +0100
Subject: [PATCH 3/3] Hook up menu bar scrollbar functionality to customize &
Options menu
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
menu-bar-scrollbar-mode custom variable updates default and
initial frame parameters.
menu-bar-scrollbar-mode command cycles the custom variable through
the available/supported values
Options ► Show Hide ► Menu Bar Scroll/Truncate menu connected to
the custom variable.
---
| 139 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 139 insertions(+)
--git a/lisp/menu-bar.el b/lisp/menu-bar.el
index e2ebd98119..0dc8757249 100644
--- a/lisp/menu-bar.el
+++ b/lisp/menu-bar.el
@@ -673,6 +673,7 @@ menu-bar-options-save
line-number-mode column-number-mode size-indication-mode
cua-mode show-paren-mode transient-mark-mode
blink-cursor-mode display-time-mode display-battery-mode
+ menu-bar-scrollbar-mode
;; These are set by other functions that don't set
;; the customized state. Having them here has the
;; side-effect that turning them off via X
@@ -1042,6 +1043,138 @@ menu-bar-showhide-tool-bar-menu-customize-enable-bottom
(interactive)
(menu-bar-set-tool-bar-position 'bottom))
+(defcustom menu-bar-scrollbar-mode nil
+ "Specify how GTK menu bars deal with the frame being too narrow to hold them.\n
+Valid values are:
+ `always' - the menu bar always has a scrollbar
+ `automatic' - a scrollbar is added when required
+ `forced-resize' - no scrollbar, the frame is forced to resize to accommodate
+ the menu bar.
+ nil (or any other value) - the menu bar is truncated\n
+Note that prior to GTK 3.16 truncation is not possible and the default
+is equivalent to 'forced-resize.\n
+Do not set this variable directly - use the customize interface to make sure
+that `default-frame-alist', `initial-frame-alist' and all existing frames
+remain in sync."
+ :version "26.2"
+ :type '(choice (const always)
+ (const automaic)
+ (const forced-resize)
+ (const nil))
+ :group 'frames
+ :initialize 'custom-initialize-default
+ :set (lambda (sym val)
+ (setq val (if (memq val '(automatic always forced-resize)) val nil))
+ (set-default sym val)
+ (modify-all-frames-parameters
+ (list (cons 'menu-bar-scrollbar val)))))
+
+(defun menu-bar-can-be-truncated ()
+ (let (version)
+ (when (boundp 'gtk-version-string)
+ (setq version (mapcar 'string-to-number (split-string gtk-version-string "\\.")))
+ (or (and (eq (car version) 3) (>= (cadr version) 16))
+ (>= (car version) 4)))))
+
+(defun menu-bar-scrollbar-next-mode (mode)
+ "Return the next menu-bar-scrollbar frame parameter value after MODE.
+Takes into account the abilities of the available GTK version."
+ (if (menu-bar-can-be-truncated)
+ (progn
+ (if (not (memq mode '(always automatic forced-resize nil))) (setq mode nil))
+ (cadr (memq mode '(nil automatic always forced-resize nil))))
+ (if (not (memq mode '(always automatic nil))) (setq mode nil))
+ (cadr (memq mode '(nil automatic always nil)))))
+
+(defun menu-bar-scrollbar-mode (&optional mode)
+ "Cycle through scroll/truncate/resize modes for GTK menu bars.\n
+If the optional parameter MODE is specified then apply that instead.
+The new mode is stored in the variable `menu-bar-scrollbar-mode' via
+the custom interface (but not automatically saved).\n
+Returns the new MODE.\n
+NOTE: pass 'default if you want to set the mode explicitly to nil.\n
+See `menu-bar-scrollbar' in Info node `(elisp)Layout Parameters' for details."
+ (interactive)
+ (if mode
+ ;; explicit mode passed, map any non-standard value back to nil
+ (setq mode (car (memq mode '(automatic always forced-resize))))
+ ;; no explicit mode: pick the new value based on our fixed progression:
+ (setq mode (menu-bar-scrollbar-next-mode
+ (or menu-bar-scrollbar-mode 'default))))
+ ;; set, apply but do not save the new value:
+ (customize-set-variable 'menu-bar-scrollbar-mode mode)
+ mode)
+
+(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-forced-resize ()
+ "Resize the frame to accommodate the menu bar."
+ (interactive)
+ (customize-set-variable 'menu-bar-scrollbar-mode 'forced-resize))
+(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-always ()
+ "Add a permanent scrollbar to the menu bar."
+ (interactive)
+ (customize-set-variable 'menu-bar-scrollbar-mode 'always))
+(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-automatic ()
+ "Add a scrollbar to the menu bar when it tries to grow past the frame edge.."
+ (interactive)
+ (customize-set-variable 'menu-bar-scrollbar-mode 'automatic))
+(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-nil ()
+ "Truncate the menu bar to fit the frame."
+ (interactive)
+ (customize-set-variable 'menu-bar-scrollbar-mode 'default))
+
+(when (featurep 'gtk)
+ (defvar menu-bar-showhide-menu-bar-scrollbar-mode-menu
+ (let ((menu (make-sparse-keymap "Menu Bar Scroll/Truncate")))
+
+ (bindings--define-key menu [showhide-menu-bar-scrollbar-mode-forced-resize]
+ '(menu-item "Resize Frame"
+ menu-bar-showhide-menu-bar-scrollbar-mode-customize-forced-resize
+ :help "Resize the frame to accommodate the menu bar"
+ :visible (display-graphic-p)
+ :button
+ (:radio . (if (menu-bar-can-be-truncated)
+ (eq (frame-parameter
+ (menu-bar-frame-for-menubar)
+ 'menu-bar-scrollbar)
+ 'forced-resize)
+ (not (memq (frame-parameter
+ (menu-bar-frame-for-menubar)
+ 'menu-bar-scrollbar)
+ '(automatic always)))))))
+
+ (bindings--define-key menu [showhide-menu-bar-scrollbar-mode-always]
+ '(menu-item "Always Scroll"
+ menu-bar-showhide-menu-bar-scrollbar-mode-customize-always
+ :help "Always add a scroll bar to the menu bar"
+ :visible (display-graphic-p)
+ :button
+ (:radio . (eq (frame-parameter (menu-bar-frame-for-menubar)
+ 'menu-bar-scrollbar)
+ 'always))))
+
+ (bindings--define-key menu [showhide-menu-bar-scrollbar-mode-automatic]
+ '(menu-item "Automatic"
+ menu-bar-showhide-menu-bar-scrollbar-mode-customize-automatic
+ :help "Display a scroll bar only when the menu is too wide"
+ :visible (display-graphic-p)
+ :button
+ (:radio . (eq (frame-parameter (menu-bar-frame-for-menubar)
+ 'menu-bar-scrollbar)
+ 'automatic))))
+
+ (bindings--define-key menu [showhide-menu-bar-scrollbar-mode-truncate]
+ '(menu-item "Truncate"
+ menu-bar-showhide-menu-bar-scrollbar-mode-customize-nil
+ :help "Truncate the menubar to fit inside the frame"
+ :visible (and (display-graphic-p)
+ (menu-bar-can-be-truncated))
+ :button
+ (:radio . (not (memq
+ (frame-parameter (menu-bar-frame-for-menubar)
+ 'menu-bar-scrollbar)
+ '(automatic always forced-resize))))))
+ menu)))
+
(when (featurep 'move-toolbar)
(defvar menu-bar-showhide-tool-bar-menu
(let ((menu (make-sparse-keymap "Tool Bar")))
@@ -1225,6 +1358,12 @@ menu-bar-showhide-menu
:visible (and (display-graphic-p) (fboundp 'x-show-tip))
:button (:toggle . tooltip-mode)))
+ (when (featurep 'gtk)
+ (bindings--define-key menu [showhide-menu-bar-scrollbar-menu]
+ `(menu-item "Menu Bar Scroll/Truncate"
+ ,menu-bar-showhide-menu-bar-scrollbar-mode-menu
+ :visible (display-graphic-p))))
+
(bindings--define-key menu [menu-bar-mode]
'(menu-item "Menu Bar" toggle-menu-bar-mode-from-frame
:help "Turn menu bar on/off"
--
2.11.0
^ permalink raw reply related [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 12:23 ` Vivek Dasmohapatra
@ 2018-10-18 12:48 ` Robert Pluim
2018-10-18 13:24 ` Vivek Dasmohapatra
2018-10-18 13:51 ` Stephen Berman
2018-10-18 13:51 ` Eli Zaretskii
1 sibling, 2 replies; 97+ messages in thread
From: Robert Pluim @ 2018-10-18 12:48 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: 22000, David Engster
I donʼt use the menu-bar, so I can't speak to the functionality, but
various documentation nits below. (menu-bar? menubar? menu bar? Iʼm
not sure what the consensus is there)
Vivek Dasmohapatra <vivek@etla.org> writes:
> featurep guards added, defcustom setting emacs version bumped.
>
>
> From 489a38cceda02e62dc50367347930713f4454f95 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Vivek=20Das=C2=A0Mohapatra?= <vivek@collabora.com>
> Date: Thu, 11 Oct 2018 13:48:47 +0100
> Subject: [PATCH 2/3] Document the new menu-bar-scrollbar frame parameter
>
> ---
> doc/lispref/frames.texi | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/doc/lispref/frames.texi b/doc/lispref/frames.texi
> index 2f9bb39886..601749d97e 100644
> --- a/doc/lispref/frames.texi
> +++ b/doc/lispref/frames.texi
> @@ -601,6 +601,10 @@ Frame Layout
> frame unchanged, so the native height of the frame (see below) will
> change instead.
>
> +If the menu bar is drawn by GTK then its behavior when it would grow
> +wider than the root frame is controlled by the @code{menu-bar-scrollbar}
> +parameter (@pxref{Layout Parameters}).
> +
What is the 'root frame'? Surely the only frame that matters is the
one displaying the menu bar?
> @item Tool Bar
> @cindex internal tool bar
> @cindex external tool bar
> @@ -1814,6 +1818,23 @@ Layout Parameters
> (@pxref{Frame Geometry}) allows to derive whether the menu bar actually
> occupies one or more lines.
>
> +@vindex menu-bar-scrollbar@r{, a frame parameter}
> +@item menu-bar-scrollbar
> +The behavior of GTK menu bars when they would otherwise grow wider than
> +the frame. Valid values are:
> +@itemize
> +@item @code{always} - Scrollbar is present, menu bar scrolls when
> too wide.
'Scrollbar is always shown' perhaps.
What does 'menu bar scrolls when too wide' mean? If the menu bar is
too wide to be displayed entirely, then the user has to take some
action to see the hidden items. This phrase seems to imply some kind
of automatic behaviour.
> +@item @code{automatic} - Scrollbar appears when menubar grows too
> wide.
'Scrollbar is shown when menubar grows too wide.'
> +@item @code{forced-resize} - No scrollbar. Growing menubar forces a frame resize.
> +@item @code{nil} (or any other value)
Iʼd drop the 'any other value' portion, so as not to constrain any
future changes. Also I think this is the one time where you use
'menubar' rather than 'menu bar'.
> +@itemize
> +@item GTK >= 3.16 - No scrollbar. Menu bar is truncated if it grows too wide.
> +@item GTK < 3,16 - Same behavior as @code{forced-resize}.
'3.16' rather than '3,16'
> +@end itemize
> +@end itemize
> +It is worth noting that for GTK before 3.16 the scrollbar adds a significant
> +amount of vertical padding to the menubar: This appears to be unavoidable.
> +
Iʼd write 'this' rather than 'This': itʼs not a separate sentence.
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 12:48 ` Robert Pluim
@ 2018-10-18 13:24 ` Vivek Dasmohapatra
2018-10-18 13:46 ` Robert Pluim
2018-10-18 13:56 ` Eli Zaretskii
2018-10-18 13:51 ` Stephen Berman
1 sibling, 2 replies; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-18 13:24 UTC (permalink / raw)
To: Robert Pluim; +Cc: 22000, David Engster
[-- Attachment #1: Type: TEXT/PLAIN, Size: 748 bytes --]
> What is the 'root frame'? Surely the only frame that matters is the
> one displaying the menu bar?
That is the root frame.
> Iʼd drop the 'any other value' portion, so as not to constrain any
> future changes.
On this specific point, no: I want to clearly document that any unrecognised
value will result in the default behaviour.
As to the rest of the changes: Presumably they can be tidied up when/if
the patches are committed? I don't particularly want to enter an infinite
edit loop here on the BTS (although thanks for the proofreading).
PS: Regarding the capital-after-a-colon question - this is a rigidly
defined area of doubt and uncertainty. There appears to be no hard-and-fast
rule, only whatever's in various house style guides.
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 8:06 ` martin rudalics
2018-10-18 12:23 ` Vivek Dasmohapatra
@ 2018-10-18 13:34 ` Eli Zaretskii
2018-10-18 14:22 ` Robert Pluim
2018-10-18 16:40 ` martin rudalics
1 sibling, 2 replies; 97+ messages in thread
From: Eli Zaretskii @ 2018-10-18 13:34 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, vivek, deng
> Date: Thu, 18 Oct 2018 10:06:27 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 22000@debbugs.gnu.org, David Engster <deng@randomsample.de>,
> "eliz@gnu.org" <eliz@gnu.org>
>
> > New patch series - I think this has all the features and functionality
> > discussed so far.
>
> Eli, I think this should go to the release branch. If it introduces any
> problems, we should find out soon enough - I think that most of our GTK
> users leave the menu bar on. But it is not just a cosmetic change.
Not a cosmetic change, indeed.
I realize that it fixes an annoying misfeature, but it does so by
introducing a significant new feature which requires quite a few code
lines. For a problem that AFAIU has been with us since time
immemoriam, I'm really uneasy with putting this on emacs-26. But I'm
fully prepared to hear arguments to the contrary.
Thanks.
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 13:24 ` Vivek Dasmohapatra
@ 2018-10-18 13:46 ` Robert Pluim
2018-10-18 13:56 ` Eli Zaretskii
1 sibling, 0 replies; 97+ messages in thread
From: Robert Pluim @ 2018-10-18 13:46 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: 22000, David Engster
Vivek Dasmohapatra <vivek@etla.org> writes:
>> What is the 'root frame'? Surely the only frame that matters is the
>> one displaying the menu bar?
>
> That is the root frame.
OK
>
>> Iʼd drop the 'any other value' portion, so as not to constrain any
>> future changes.
>
> On this specific point, no: I want to clearly document that any unrecognised
> value will result in the default behaviour.
>
OK
> As to the rest of the changes: Presumably they can be tidied up when/if
> the patches are committed? I don't particularly want to enter an infinite
> edit loop here on the BTS (although thanks for the proofreading).
I was not proposing such a loop, merely offering suggestions that I
thought would aid clarity.
Since weʼre on the subject: I scanned the other patches, and there are
various minor formatting issues there: no double space at the end of
sentence, missing period at the end of sentence, plus some stray "\n"
in lisp doc strings. No need to resend, though :-)
> PS: Regarding the capital-after-a-colon question - this is a rigidly
> defined area of doubt and uncertainty. There appears to be no hard-and-fast
> rule, only whatever's in various house style guides.
Iʼd argue that based on consistency capital letters should only be
used at the start of a sentence, and in this case itʼs a dependent
clause, not a separate sentence. But thatʼs not a very strong rule,
Iʼll admit.
Robert
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 12:48 ` Robert Pluim
2018-10-18 13:24 ` Vivek Dasmohapatra
@ 2018-10-18 13:51 ` Stephen Berman
2018-10-18 14:31 ` Robert Pluim
1 sibling, 1 reply; 97+ messages in thread
From: Stephen Berman @ 2018-10-18 13:51 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: 22000, David Engster
On Thu, 18 Oct 2018 14:48:21 +0200 Robert Pluim <rpluim@gmail.com> wrote:
> I donʼt use the menu-bar, so I can't speak to the functionality, but
> various documentation nits below. (menu-bar? menubar? menu bar? Iʼm
> not sure what the consensus is there)
The status quo in the Emacs manual favors two words, also for related
terms:
$ grep -i menubar emacs.info | wc -l
27
$ grep -i menu-bar emacs.info | wc -l
14
$ grep -i "menu bar" emacs.info | wc -l
80
$ grep -i scrollbar emacs.info | wc -l
10
$ grep -i scroll-bar emacs.info | wc -l
19
$ grep -i "scroll bar" emacs.info | wc -l
72
$ grep -i toolbar emacs.info | wc -l
3
$ grep -i tool-bar emacs.info | wc -l
8
$ grep -i "tool bar" emacs.info | wc -l
48
(Though as Ralph Waldo Emerson (I think) said, consistency is the
hobgoblin of small minds. Or is that "hob-goblin" or "hob goblin"?)
Steve Berman
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 12:23 ` Vivek Dasmohapatra
2018-10-18 12:48 ` Robert Pluim
@ 2018-10-18 13:51 ` Eli Zaretskii
2018-10-18 17:26 ` Vivek Dasmohapatra
1 sibling, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2018-10-18 13:51 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: 22000, deng
> Date: Thu, 18 Oct 2018 13:23:26 +0100 (BST)
> From: Vivek Dasmohapatra <vivek@etla.org>
> cc: 22000@debbugs.gnu.org, David Engster <deng@randomsample.de>,
> "eliz@gnu.org" <eliz@gnu.org>
>
> +/* Sets up the menubar style for scrolling/non-scrolling modes.
> + Reparents the menubar directly into the vbox for non-scrolling
> + mode and adds a scrolledwindow+viewport for scrolling modes. */
This commentary is n ot in the style we (and you elsewhere in the
patch) use: you should say "Set up", not "Sets up".
> +#if GTK_CHECK_VERSION (3, 8, 0)
> + gtk_container_add (GTK_CONTAINER (x->menubar_viewport), x->menubar_widget);
> +#else
> + gtk_scrolled_window_add_with_viewport (GTK_SCROLLED_WINDOW (x->menubar_viewport), x->menubar_widget);
Please break long lines into several shorter ones.
> +#if GTK_CHECK_VERSION(3, 16, 0)
> + /* Always want the scrollable container for capable-enough GTK versions */
> + menubar_scrollbox (f, 1);
Comments should be complete sentences, start with a capital letter,
and end in a period and 2 spaces.
> +@itemize
> +@item @code{always} - Scrollbar is present, menu bar scrolls when too wide.
> +@item @code{automatic} - Scrollbar appears when menubar grows too wide.
> +@item @code{forced-resize} - No scrollbar. Growing menubar forces a frame resize.
This is not the correct way of using @itemize. You should do this
instead:
@itemize
@item
@code{always} - Scrollbar is present, menu bar scrolls when too wide.
@item
@code{automatic} - Scrollbar appears when menubar grows too wide.
etc. (Actually, I'd suggest using "@table @code" here, not @itemize.)
Also, please use "--" for an en-dash, not a single "-".
> +(defcustom menu-bar-scrollbar-mode nil
> + "Specify how GTK menu bars deal with the frame being too narrow to hold them.\n
> +Valid values are:
> + `always' - the menu bar always has a scrollbar
> + `automatic' - a scrollbar is added when required
> + `forced-resize' - no scrollbar, the frame is forced to resize to accommodate
> + the menu bar.
> + nil (or any other value) - the menu bar is truncated\n
> +Note that prior to GTK 3.16 truncation is not possible and the default
> +is equivalent to 'forced-resize.\n
Do you really need these explicit \n newlines?
> +(defun menu-bar-scrollbar-mode (&optional mode)
> + "Cycle through scroll/truncate/resize modes for GTK menu bars.\n
> +If the optional parameter MODE is specified then apply that instead.
> +The new mode is stored in the variable `menu-bar-scrollbar-mode' via
> +the custom interface (but not automatically saved).\n
> +Returns the new MODE.\n
> +NOTE: pass 'default if you want to set the mode explicitly to nil.\n
Likewise here.
More generally, shouldn't this mode have "gtk" somewhere in the name?
Or, if we hope to implement it for other toolkits at some future date,
the doc string should not say "GTK menu bars", it should say "menu
bars" and then have a note that this currently has effect only with
GTK menus.
> +(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-forced-resize ()
> + "Resize the frame to accommodate the menu bar."
> + (interactive)
> + (customize-set-variable 'menu-bar-scrollbar-mode 'forced-resize))
> +(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-always ()
> + "Add a permanent scrollbar to the menu bar."
> + (interactive)
> + (customize-set-variable 'menu-bar-scrollbar-mode 'always))
> +(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-automatic ()
> + "Add a scrollbar to the menu bar when it tries to grow past the frame edge.."
> + (interactive)
> + (customize-set-variable 'menu-bar-scrollbar-mode 'automatic))
> +(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-nil ()
> + "Truncate the menu bar to fit the frame."
> + (interactive)
> + (customize-set-variable 'menu-bar-scrollbar-mode 'default))
I think doc strings of these functions are too laconic for interactive
functions.
Thanks.
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 13:24 ` Vivek Dasmohapatra
2018-10-18 13:46 ` Robert Pluim
@ 2018-10-18 13:56 ` Eli Zaretskii
2018-10-18 17:08 ` Vivek Dasmohapatra
1 sibling, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2018-10-18 13:56 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: rpluim, 22000, deng
> Date: Thu, 18 Oct 2018 14:24:14 +0100 (BST)
> From: Vivek Dasmohapatra <vivek@etla.org>
> Cc: 22000@debbugs.gnu.org, David Engster <deng@randomsample.de>
>
> > What is the 'root frame'? Surely the only frame that matters is the
> > one displaying the menu bar?
>
> That is the root frame.
We don't have such terminology in Emacs.
Maybe I misunderstand you: what other frames, except "root frames" do
you see in Emacs?
> PS: Regarding the capital-after-a-colon question - this is a rigidly
> defined area of doubt and uncertainty. There appears to be no hard-and-fast
> rule, only whatever's in various house style guides.
FWIW, I find the capital-letter style here jarring.
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 13:34 ` Eli Zaretskii
@ 2018-10-18 14:22 ` Robert Pluim
2018-10-18 16:41 ` martin rudalics
2018-10-18 16:40 ` martin rudalics
1 sibling, 1 reply; 97+ messages in thread
From: Robert Pluim @ 2018-10-18 14:22 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22000, vivek, deng
[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Thu, 18 Oct 2018 10:06:27 +0200
>> From: martin rudalics <rudalics@gmx.at>
>> CC: 22000@debbugs.gnu.org, David Engster <deng@randomsample.de>,
>> "eliz@gnu.org" <eliz@gnu.org>
>>
>> > New patch series - I think this has all the features and functionality
>> > discussed so far.
>>
>> Eli, I think this should go to the release branch. If it introduces any
>> problems, we should find out soon enough - I think that most of our GTK
>> users leave the menu bar on. But it is not just a cosmetic change.
>
> Not a cosmetic change, indeed.
>
> I realize that it fixes an annoying misfeature, but it does so by
> introducing a significant new feature which requires quite a few code
> lines. For a problem that AFAIU has been with us since time
> immemoriam, I'm really uneasy with putting this on emacs-26. But I'm
> fully prepared to hear arguments to the contrary.
Iʼve tried the patch now, and am seeing some minor display glitches
from emacs -Q. The space allocated for the menu bar seems slightly too
small, resulting in a dotted line underneath it, see screenshot. This
is with gtk 3.22.30.
[-- Attachment #2: Selection_045.png --]
[-- Type: image/png, Size: 14740 bytes --]
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 13:51 ` Stephen Berman
@ 2018-10-18 14:31 ` Robert Pluim
0 siblings, 0 replies; 97+ messages in thread
From: Robert Pluim @ 2018-10-18 14:31 UTC (permalink / raw)
To: Stephen Berman; +Cc: 22000, Vivek Dasmohapatra, David Engster
Stephen Berman <stephen.berman@gmx.net> writes:
> On Thu, 18 Oct 2018 14:48:21 +0200 Robert Pluim <rpluim@gmail.com> wrote:
>
>> I donʼt use the menu-bar, so I can't speak to the functionality, but
>> various documentation nits below. (menu-bar? menubar? menu bar? Iʼm
>> not sure what the consensus is there)
>
> The status quo in the Emacs manual favors two words, also for related
> terms:
>
> $ grep -i menubar emacs.info | wc -l
> 27
> $ grep -i menu-bar emacs.info | wc -l
> 14
> $ grep -i "menu bar" emacs.info | wc -l
> 80
> $ grep -i scrollbar emacs.info | wc -l
> 10
> $ grep -i scroll-bar emacs.info | wc -l
> 19
> $ grep -i "scroll bar" emacs.info | wc -l
> 72
> $ grep -i toolbar emacs.info | wc -l
> 3
> $ grep -i tool-bar emacs.info | wc -l
> 8
> $ grep -i "tool bar" emacs.info | wc -l
> 48
I suspect quite a few of those matches are commands or variables, so
not that easy to fix.
> (Though as Ralph Waldo Emerson (I think) said, consistency is the
> hobgoblin of small minds. Or is that "hob-goblin" or "hob goblin"?)
Indeed.
Robert
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 13:34 ` Eli Zaretskii
2018-10-18 14:22 ` Robert Pluim
@ 2018-10-18 16:40 ` martin rudalics
2018-10-18 17:07 ` Eli Zaretskii
1 sibling, 1 reply; 97+ messages in thread
From: martin rudalics @ 2018-10-18 16:40 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22000, vivek, deng
> I realize that it fixes an annoying misfeature, but it does so by
> introducing a significant new feature which requires quite a few code
> lines. For a problem that AFAIU has been with us since time
> immemoriam, I'm really uneasy with putting this on emacs-26. But I'm
> fully prepared to hear arguments to the contrary.
My sole argument is that the feature does not introduce any hidden or
subtle changes. As long as users have a recent enough GTK installed
and use menu bars any bugs should be easy to find. The glitch Robert
has detected is a proof for this claim (my GTK was too old for that).
In either case I'll be just happy to put this problem to a rest - on
the release branch or on master.
martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 14:22 ` Robert Pluim
@ 2018-10-18 16:41 ` martin rudalics
2018-10-19 7:41 ` Robert Pluim
0 siblings, 1 reply; 97+ messages in thread
From: martin rudalics @ 2018-10-18 16:41 UTC (permalink / raw)
To: Robert Pluim, Eli Zaretskii; +Cc: 22000, vivek, deng
> Iʼve tried the patch now,
Thank you. Please try also customizing the option from the menu bar
and please also try its main feature: Make the frame sufficently
narrow, type M-x dired RET RET, and test whether the menu bar gets
truncated instead of resizing the frame.
> and am seeing some minor display glitches
> from emacs -Q. The space allocated for the menu bar seems slightly too
> small, resulting in a dotted line underneath it, see screenshot. This
> is with gtk 3.22.30.
From that screenshot it's also evident that descenders are truncated,
in particular the "p" in Options, Help ...
martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 16:40 ` martin rudalics
@ 2018-10-18 17:07 ` Eli Zaretskii
2018-10-18 17:13 ` Vivek Dasmohapatra
0 siblings, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2018-10-18 17:07 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, vivek, deng
> Date: Thu, 18 Oct 2018 18:40:50 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: vivek@etla.org, 22000@debbugs.gnu.org, deng@randomsample.de
>
> My sole argument is that the feature does not introduce any hidden or
> subtle changes. As long as users have a recent enough GTK installed
> and use menu bars any bugs should be easy to find. The glitch Robert
> has detected is a proof for this claim (my GTK was too old for that).
>
> In either case I'll be just happy to put this problem to a rest - on
> the release branch or on master.
Oh, I'm quite sure we want this on master, I'm just struggling with
the idea of having all that non-trivial code on the release branch.
Does anyone else have an opinion, or can offer one?
Thanks.
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 13:56 ` Eli Zaretskii
@ 2018-10-18 17:08 ` Vivek Dasmohapatra
2018-10-18 18:16 ` Eli Zaretskii
0 siblings, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-18 17:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rpluim, 22000, deng
> Maybe I misunderstand you: what other frames, except "root frames" do
> you see in Emacs?
I had to call it something - root window already means something else in X.
I just meant the top-level enclosing widget. I am happy do describe it with
any reasonably accurate term.
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 17:07 ` Eli Zaretskii
@ 2018-10-18 17:13 ` Vivek Dasmohapatra
2018-10-19 7:26 ` Robert Pluim
0 siblings, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-18 17:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22000, deng
> Oh, I'm quite sure we want this on master, I'm just struggling with
> the idea of having all that non-trivial code on the release branch.
>
> Does anyone else have an opinion, or can offer one?
Only that I find the current size-jitter extremely annoying, which
is admittedly a very subjective thing. The actual merge window does
not matter so much to me because, well, I already have a patched
emacs on my system(s) by this point.
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 13:51 ` Eli Zaretskii
@ 2018-10-18 17:26 ` Vivek Dasmohapatra
2018-10-18 18:20 ` Eli Zaretskii
0 siblings, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-18 17:26 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22000, deng
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1897 bytes --]
>> +(defcustom menu-bar-scrollbar-mode nil
>> + "Specify how GTK menu bars deal with the frame being too narrow to hold them.\n
>> +Valid values are:
>> + `always' - the menu bar always has a scrollbar
>> + `automatic' - a scrollbar is added when required
>> + `forced-resize' - no scrollbar, the frame is forced to resize to accommodate
>> + the menu bar.
>> + nil (or any other value) - the menu bar is truncated\n
>> +Note that prior to GTK 3.16 truncation is not possible and the default
>> +is equivalent to 'forced-resize.\n
>
> Do you really need these explicit \n newlines?
I wouldn't say need but I find they make the documentation more readable,
per item 3 in (elisp)Top > Tips > Documentation tips … D.6 Tips for…
> More generally, shouldn't this mode have "gtk" somewhere in the name?
> Or, if we hope to implement it for other toolkits at some future date,
> the doc string should not say "GTK menu bars", it should say "menu
> bars" and then have a note that this currently has effect only with
> GTK menus.
I prefer the second option, I will adjust the docstrings accordingly.
>> +(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-nil ()
>> + "Truncate the menu bar to fit the frame."
>> + (interactive)
>> + (customize-set-variable 'menu-bar-scrollbar-mode 'default))
>
> I think doc strings of these functions are too laconic for interactive
> functions.
AIUI they are interactive purely because that is a requirement for the
way they are used by the menu infrastructure, not because they are
intended to be used as commands with M-x or similar by the user.
The other …-customize-… shim commands in that file are similarly laconically
documented. However if the objection still stands, I will add more verbose
docstrings.
I will make the other changes suggested (to which I have not responded
individually here).
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 17:08 ` Vivek Dasmohapatra
@ 2018-10-18 18:16 ` Eli Zaretskii
2018-10-18 18:34 ` Vivek Dasmohapatra
0 siblings, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2018-10-18 18:16 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: rpluim, 22000, deng
> Date: Thu, 18 Oct 2018 18:08:42 +0100 (BST)
> From: Vivek Dasmohapatra <vivek@etla.org>
> cc: rpluim@gmail.com, 22000@debbugs.gnu.org, deng@randomsample.de
>
> > Maybe I misunderstand you: what other frames, except "root frames" do
> > you see in Emacs?
>
> I had to call it something - root window already means something else in X.
> I just meant the top-level enclosing widget. I am happy do describe it with
> any reasonably accurate term.
I guess I'm asking why not just say "frame"?
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 17:26 ` Vivek Dasmohapatra
@ 2018-10-18 18:20 ` Eli Zaretskii
2018-10-18 18:32 ` Vivek Dasmohapatra
2018-10-18 19:55 ` Drew Adams
0 siblings, 2 replies; 97+ messages in thread
From: Eli Zaretskii @ 2018-10-18 18:20 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: 22000, deng
> Date: Thu, 18 Oct 2018 18:26:34 +0100 (BST)
> From: Vivek Dasmohapatra <vivek@etla.org>
> cc: rudalics@gmx.at, 22000@debbugs.gnu.org, deng@randomsample.de
>
> >> + nil (or any other value) - the menu bar is truncated\n
> >> +Note that prior to GTK 3.16 truncation is not possible and the default
> >> +is equivalent to 'forced-resize.\n
> >
> > Do you really need these explicit \n newlines?
>
> I wouldn't say need but I find they make the documentation more readable,
> per item 3 in (elisp)Top > Tips > Documentation tips … D.6 Tips for…
Sure, but why not have them literally, so that reading the doc string
in the code will also be easier. Like this:
(defun menu-bar-scrollbar-mode (&optional mode)
"Cycle through scroll/truncate/resize modes for GTK menu bars.
If the optional parameter MODE is specified then apply that instead.
The new mode is stored in the variable `menu-bar-scrollbar-mode' via
the custom interface (but not automatically saved).
Returns the new MODE.
NOTE: pass 'default if you want to set the mode explicitly to nil.
See `menu-bar-scrollbar' in Info node `(elisp)Layout Parameters' for details."
> I will make the other changes suggested (to which I have not responded
> individually here).
Thanks.
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 18:20 ` Eli Zaretskii
@ 2018-10-18 18:32 ` Vivek Dasmohapatra
2018-10-18 19:55 ` Drew Adams
1 sibling, 0 replies; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-18 18:32 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22000, deng
On Thu, 18 Oct 2018, Eli Zaretskii wrote:
> Sure, but why not have them literally, so that reading the doc string
> in the code will also be easier. Like this:
Oh, right! Sure, no problem. I vaguely recall some problem with docstring
highlighting but that was years ago (sometime around emacs 19?).
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 18:16 ` Eli Zaretskii
@ 2018-10-18 18:34 ` Vivek Dasmohapatra
0 siblings, 0 replies; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-18 18:34 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rpluim, 22000, deng
>> I had to call it something - root window already means something else in X.
>> I just meant the top-level enclosing widget. I am happy do describe it with
>> any reasonably accurate term.
>
> I guess I'm asking why not just say "frame"?
A fair question. I think I was just confused from hopping between X, GTK
and emacs terminology while investigating the bug. I'll do that.
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 18:20 ` Eli Zaretskii
2018-10-18 18:32 ` Vivek Dasmohapatra
@ 2018-10-18 19:55 ` Drew Adams
2018-10-19 6:23 ` Eli Zaretskii
1 sibling, 1 reply; 97+ messages in thread
From: Drew Adams @ 2018-10-18 19:55 UTC (permalink / raw)
To: Eli Zaretskii, Vivek Dasmohapatra; +Cc: 22000, deng
> (defun menu-bar-scrollbar-mode (&optional mode)
> "Cycle through scroll/truncate/resize modes for GTK menu bars.
>
> If the optional parameter MODE is specified then apply that instead.
> The new mode is stored in the variable `menu-bar-scrollbar-mode' via
> the custom interface (but not automatically saved).
>
> Returns the new MODE.
>
> NOTE: pass 'default if you want to set the mode explicitly to nil.
>
> See `menu-bar-scrollbar' in Info node `(elisp)Layout Parameters' for details."
FWIW - AFAIK, it is not Emacs convention to add a blank line between
the first and second lines of text in a doc string.
I believe the conventional approach is this:
"Cycle through scroll/truncate/resize modes for GTK menu bars.
If the optional parameter MODE is specified then apply that instead.
..."
not this:
"Cycle through scroll/truncate/resize modes for GTK menu bars.
If the optional parameter MODE is specified then apply that instead.
..."
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 19:55 ` Drew Adams
@ 2018-10-19 6:23 ` Eli Zaretskii
0 siblings, 0 replies; 97+ messages in thread
From: Eli Zaretskii @ 2018-10-19 6:23 UTC (permalink / raw)
To: Drew Adams; +Cc: 22000, vivek, deng
> Date: Thu, 18 Oct 2018 12:55:09 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 22000@debbugs.gnu.org, deng@randomsample.de
>
> FWIW - AFAIK, it is not Emacs convention to add a blank line between
> the first and second lines of text in a doc string.
Quite a few of doc strings do leave an empty line there, and I find
nothing wrong with that.
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 17:13 ` Vivek Dasmohapatra
@ 2018-10-19 7:26 ` Robert Pluim
2018-10-19 8:23 ` Eli Zaretskii
0 siblings, 1 reply; 97+ messages in thread
From: Robert Pluim @ 2018-10-19 7:26 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: 22000, deng
Vivek Dasmohapatra <vivek@etla.org> writes:
>> Oh, I'm quite sure we want this on master, I'm just struggling with
>> the idea of having all that non-trivial code on the release branch.
>>
>> Does anyone else have an opinion, or can offer one?
>
> Only that I find the current size-jitter extremely annoying, which
> is admittedly a very subjective thing. The actual merge window does
> not matter so much to me because, well, I already have a patched
> emacs on my system(s) by this point.
In favour of putting it on emacs-26 is that it resolves the spewing of
Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion
'extra_space >= 0' failed
when I run emacs with GDK scaling.
Robert
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-18 16:41 ` martin rudalics
@ 2018-10-19 7:41 ` Robert Pluim
2018-10-19 8:34 ` martin rudalics
0 siblings, 1 reply; 97+ messages in thread
From: Robert Pluim @ 2018-10-19 7:41 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, vivek, deng
martin rudalics <rudalics@gmx.at> writes:
>> Iʼve tried the patch now,
>
> Thank you. Please try also customizing the option from the menu bar
> and please also try its main feature: Make the frame sufficently
> narrow, type M-x dired RET RET, and test whether the menu bar gets
> truncated instead of resizing the frame.
>
Something very strange is going on: menu-bar-scrollbar-mode is nil by
default, so why am I seeing a scrollbar at all?
Even stranger: with KDE I see the scrollbar, but running the same
emacs binary under GNOME I donʼt (and the menubar is truncated when
the frame is too narrow, so the functionality is fine).
>> and am seeing some minor display glitches
>> from emacs -Q. The space allocated for the menu bar seems slightly too
>> small, resulting in a dotted line underneath it, see screenshot. This
>> is with gtk 3.22.30.
>
> From that screenshot it's also evident that descenders are truncated,
> in particular the "p" in Options, Help ...
Yes. Iʼm thinking there should be no scrollbar at all.
<Coffee kicks in>
Iʼm seeing a *vertical* scroll bar. So probably this is just a slight
miscalculation of the menubar height (but then why is it different
under KDE than GNOME?). Would it make sense to start playing with
gtkutil.c:MENUBAR_STYLESHEET ?
Robert
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-19 7:26 ` Robert Pluim
@ 2018-10-19 8:23 ` Eli Zaretskii
2018-10-19 9:25 ` Robert Pluim
0 siblings, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2018-10-19 8:23 UTC (permalink / raw)
To: Robert Pluim; +Cc: 22000, vivek, deng
> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 22000@debbugs.gnu.org, deng@randomsample.de
> Date: Fri, 19 Oct 2018 09:26:28 +0200
>
> In favour of putting it on emacs-26 is that it resolves the spewing of
>
> Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion
> 'extra_space >= 0' failed
>
> when I run emacs with GDK scaling.
Thanks. I understand the advantages of the changeset, what I'm not
sure about is whether these advantages outweigh the danger in putting
such non-trivial changes on the release branch. The glitches reported
by you and others just in the last two days seem to indicate that we
will be in for more surprises, don't you think?
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-19 7:41 ` Robert Pluim
@ 2018-10-19 8:34 ` martin rudalics
2018-10-19 9:14 ` Robert Pluim
2018-10-19 14:17 ` Stephen Berman
0 siblings, 2 replies; 97+ messages in thread
From: martin rudalics @ 2018-10-19 8:34 UTC (permalink / raw)
To: Robert Pluim; +Cc: 22000, vivek, Stephen Berman
> Something very strange is going on: menu-bar-scrollbar-mode is nil by
> default, so why am I seeing a scrollbar at all?
Can you please describe the steps you performed? Is this with -Q or
in a session where you turned the menu bar on later?
> Even stranger: with KDE I see the scrollbar, but running the same
> emacs binary under GNOME I donʼt (and the menubar is truncated when
> the frame is too narrow, so the functionality is fine).
Is there no way to turn the scroll bar off under KDE? Can you turn
the scroll bar on under GNOME?
> Yes. Iʼm thinking there should be no scrollbar at all.
>
> <Coffee kicks in>
>
> Iʼm seeing a *vertical* scroll bar. So probably this is just a slight
> miscalculation of the menubar height (but then why is it different
> under KDE than GNOME?). Would it make sense to start playing with
> gtkutil.c:MENUBAR_STYLESHEET ?
I think so. But I'd like to see at least one or two other persons
with sufficiently new GTKs kick in (Stephen, pretty please) so we get
a more complete picture of which problems may occur.
Thanks, martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-19 8:34 ` martin rudalics
@ 2018-10-19 9:14 ` Robert Pluim
2018-10-19 13:44 ` Robert Pluim
2018-10-19 14:17 ` Stephen Berman
1 sibling, 1 reply; 97+ messages in thread
From: Robert Pluim @ 2018-10-19 9:14 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, vivek, Stephen Berman
martin rudalics <rudalics@gmx.at> writes:
>> Something very strange is going on: menu-bar-scrollbar-mode is nil by
>> default, so why am I seeing a scrollbar at all?
>
> Can you please describe the steps you performed? Is this with -Q or
> in a session where you turned the menu bar on later?
emacs -Q. But I was confused about the scrollbar :-)
>> Even stranger: with KDE I see the scrollbar, but running the same
>> emacs binary under GNOME I donʼt (and the menubar is truncated when
>> the frame is too narrow, so the functionality is fine).
>
> Is there no way to turn the scroll bar off under KDE? Can you turn
> the scroll bar on under GNOME?
Under GNOME, I see truncation when the frame is too narrow. If I set
menu-bar-scrollbar-mode to 'always', I get a horizontal scrollbar when
the frame is too narrow. (I haven't retried KDE yet).
So itʼs all working fine, except for the visual glitch under KDE.
>> Yes. Iʼm thinking there should be no scrollbar at all.
>>
>> <Coffee kicks in>
>>
>> Iʼm seeing a *vertical* scroll bar. So probably this is just a slight
>> miscalculation of the menubar height (but then why is it different
>> under KDE than GNOME?). Would it make sense to start playing with
>> gtkutil.c:MENUBAR_STYLESHEET ?
>
> I think so. But I'd like to see at least one or two other persons
> with sufficiently new GTKs kick in (Stephen, pretty please) so we get
> a more complete picture of which problems may occur.
".mbtrunc * { border-width: 1px; margin-top: -2px; margin-bottom: -2px; }\n" \
Iʼm thinking maybe that margin-bottom should be 0px or something? Iʼll
see if I can try that later.
Robert
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-19 8:23 ` Eli Zaretskii
@ 2018-10-19 9:25 ` Robert Pluim
0 siblings, 0 replies; 97+ messages in thread
From: Robert Pluim @ 2018-10-19 9:25 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22000, vivek, deng
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, 22000@debbugs.gnu.org, deng@randomsample.de
>> Date: Fri, 19 Oct 2018 09:26:28 +0200
>>
>> In favour of putting it on emacs-26 is that it resolves the spewing of
>>
>> Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion
>> 'extra_space >= 0' failed
>>
>> when I run emacs with GDK scaling.
>
> Thanks. I understand the advantages of the changeset, what I'm not
> sure about is whether these advantages outweigh the danger in putting
> such non-trivial changes on the release branch. The glitches reported
> by you and others just in the last two days seem to indicate that we
> will be in for more surprises, don't you think?
Yes. From painful experience various versions of GTK have different
behaviours that aren't detected until the changes are more widely
deployed (but you know that :-) )
Robert
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-19 9:14 ` Robert Pluim
@ 2018-10-19 13:44 ` Robert Pluim
2018-10-19 17:57 ` martin rudalics
0 siblings, 1 reply; 97+ messages in thread
From: Robert Pluim @ 2018-10-19 13:44 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, vivek, Stephen Berman
Robert Pluim <rpluim@gmail.com> writes:
>>> Iʼm seeing a *vertical* scroll bar. So probably this is just a slight
>>> miscalculation of the menubar height (but then why is it different
>>> under KDE than GNOME?). Would it make sense to start playing with
>>> gtkutil.c:MENUBAR_STYLESHEET ?
>>
>> I think so. But I'd like to see at least one or two other persons
>> with sufficiently new GTKs kick in (Stephen, pretty please) so we get
>> a more complete picture of which problems may occur.
>
> ".mbtrunc * { border-width: 1px; margin-top: -2px; margin-bottom: -2px; }\n" \
>
> Iʼm thinking maybe that margin-bottom should be 0px or something? Iʼll
> see if I can try that later.
Further testing under KDE shows three things:
1. I get a vertical scrollbar on the right for the echo
area/minibuffer line but not the menubar using emacs -Q on
unmodified emacs-26, so that was not introduced by this patch
2. In unmodified emacs-26, the line separating the menu bar from the
tool bar is solid, not dotted
3. I can get rid of the menu bar truncation issue by setting
margin-bottom to 10px (but I still have the vertical scrollbar).
Robert
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-19 8:34 ` martin rudalics
2018-10-19 9:14 ` Robert Pluim
@ 2018-10-19 14:17 ` Stephen Berman
2018-10-19 14:44 ` Vivek Dasmohapatra
2018-10-19 17:57 ` martin rudalics
1 sibling, 2 replies; 97+ messages in thread
From: Stephen Berman @ 2018-10-19 14:17 UTC (permalink / raw)
To: martin rudalics; +Cc: Robert Pluim, 22000, vivek
On Fri, 19 Oct 2018 10:34:08 +0200 martin rudalics <rudalics@gmx.at> wrote:
>> Something very strange is going on: menu-bar-scrollbar-mode is nil by
>> default, so why am I seeing a scrollbar at all?
>
> Can you please describe the steps you performed? Is this with -Q or
> in a session where you turned the menu bar on later?
>
>> Even stranger: with KDE I see the scrollbar, but running the same
>> emacs binary under GNOME I donʼt (and the menubar is truncated when
>> the frame is too narrow, so the functionality is fine).
>
> Is there no way to turn the scroll bar off under KDE? Can you turn
> the scroll bar on under GNOME?
>
>> Yes. Iʼm thinking there should be no scrollbar at all.
>>
>> <Coffee kicks in>
>>
>> Iʼm seeing a *vertical* scroll bar. So probably this is just a slight
>> miscalculation of the menubar height (but then why is it different
>> under KDE than GNOME?). Would it make sense to start playing with
>> gtkutil.c:MENUBAR_STYLESHEET ?
>
> I think so. But I'd like to see at least one or two other persons
> with sufficiently new GTKs kick in (Stephen, pretty please) so we get
> a more complete picture of which problems may occur.
I've applied the patches in
https://lists.gnu.org/archive/html/bug-gnu-emacs/2018-10/msg00514.html
to current master and everything seems to be working as it should. This
is with GTK+ 3.22.30 and Openbox using several GNOME libraries; I don't
have a complete GNOME DE but I may be able to try with KDE over the
weekend.
There are a couple of visual oddities: when the `menu-bar-scrollbar'
frame parameter has the value nil or `forced-resize' (or when the item
"Menu Bar Scroll/Truncate" of the Options->Show/Hide menu is set to
"Truncate" or "Resize Frame"), then there is no thin dividing line
between the menu bar and the tool bar (in contrast to Emacs built
without this patchset), and in addition, when a menu bar menu is open,
the dividing lines in the menu are rather thick; but when the
`menu-bar-scrollbar' frame parameter has the value `automatic', the thin
dividing line between the menu bar and the tool bar is displayed (and
the menu bar itself is noticeably thicker than in Emacs built without
this patchset), and the dividing lines in an open menu are thinner,
though not as thin as the line between the menu and tool bars (in Emacs
built without this patchset the menu dividers are just as thin as the
the divider between the menu and tool bars); with the parameter value
`always' the scroll bar replaces the dividing line between the menu and
tool bars, and the menu dividers have the same thickness as with the
`automatic' setting.
Steve Berman
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-19 14:17 ` Stephen Berman
@ 2018-10-19 14:44 ` Vivek Dasmohapatra
2018-10-19 16:21 ` Stephen Berman
2018-10-19 17:57 ` martin rudalics
1 sibling, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-19 14:44 UTC (permalink / raw)
To: Stephen Berman; +Cc: Robert Pluim, 22000
> There are a couple of visual oddities: when the `menu-bar-scrollbar'
> frame parameter has the value nil or `forced-resize' (or when the item
Could you grab screenshots (just the rectangle around the glitch will
suffice - don't need the whole X window or screen)?
Makes it easier to compare/debug/etc.
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-19 14:44 ` Vivek Dasmohapatra
@ 2018-10-19 16:21 ` Stephen Berman
2018-10-21 15:44 ` Vivek Dasmohapatra
2018-10-21 15:50 ` Vivek Dasmohapatra
0 siblings, 2 replies; 97+ messages in thread
From: Stephen Berman @ 2018-10-19 16:21 UTC (permalink / raw)
To: Vivek Dasmohapatra; +Cc: Robert Pluim, 22000
[-- Attachment #1: Type: text/plain, Size: 584 bytes --]
On Fri, 19 Oct 2018 15:44:21 +0100 (BST) Vivek Dasmohapatra <vivek@etla.org> wrote:
>> There are a couple of visual oddities: when the `menu-bar-scrollbar'
>> frame parameter has the value nil or `forced-resize' (or when the item
>
> Could you grab screenshots (just the rectangle around the glitch will
> suffice - don't need the whole X window or screen)?
>
> Makes it easier to compare/debug/etc.
Here's a screenshot showing the the menu and tool bars in Emacs without
your patches (left), with patches and menu-bar-scrollbar set to
`automatic' (middle) and set to nil (right):
[-- Attachment #2: menubar1.png --]
[-- Type: image/png, Size: 8334 bytes --]
[-- Attachment #3: Type: text/plain, Size: 350 bytes --]
I don't know how to grab a screenshot with an open menu -- as soon as
the menu loses focus (needed to run the screenshot program) it
disappears. So I photographed the screen and grabbed a screenshot of the
images to reduce the size, though it's still more than 500kB and the
quality is poor -- sorry, but maybe it's good enough to see the issues:
[-- Attachment #4: menubar2.png --]
[-- Type: image/png, Size: 578985 bytes --]
[-- Attachment #5: Type: text/plain, Size: 14 bytes --]
Steve Berman
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-19 13:44 ` Robert Pluim
@ 2018-10-19 17:57 ` martin rudalics
2018-10-23 10:07 ` Robert Pluim
0 siblings, 1 reply; 97+ messages in thread
From: martin rudalics @ 2018-10-19 17:57 UTC (permalink / raw)
To: Robert Pluim; +Cc: 22000, vivek, Stephen Berman
> Further testing under KDE shows three things:
>
> 1. I get a vertical scrollbar on the right for the echo
> area/minibuffer line but not the menubar using emacs -Q on
> unmodified emacs-26, so that was not introduced by this patch
Hmmm... Could you investigatte why this happens? Note that the echo
area/minibuffer window by default hay a vertical scroll bar, just that
it is hidden when the window height is less than the minimum length of
the slider, see the following part of gtkutil.c:
if (hidden)
{
/* No room. Hide scroll bar as some themes output a warning if
the height is less than the min size. */
gtk_widget_hide (wparent);
gtk_widget_hide (wscroll);
}
If you put a breakpoint at the 'if' you should see what's different
between GNOME and KDE.
> 2. In unmodified emacs-26, the line separating the menu bar from the
> tool bar is solid, not dotted
>
> 3. I can get rid of the menu bar truncation issue by setting
> margin-bottom to 10px
When you do that does the spearator become solid again?
> (but I still have the vertical scrollbar).
Funny. I suppose that vertical menu bar scroll bar is of no use, that
is, you don't get any truncated items in a second row?
martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-19 14:17 ` Stephen Berman
2018-10-19 14:44 ` Vivek Dasmohapatra
@ 2018-10-19 17:57 ` martin rudalics
1 sibling, 0 replies; 97+ messages in thread
From: martin rudalics @ 2018-10-19 17:57 UTC (permalink / raw)
To: Stephen Berman; +Cc: Robert Pluim, 22000, vivek
> I've applied the patches in
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2018-10/msg00514.html
> to current master and everything seems to be working as it should. This
> is with GTK+ 3.22.30 and Openbox using several GNOME libraries; I don't
> have a complete GNOME DE but I may be able to try with KDE over the
> weekend.
Thank you very much for testing.
> There are a couple of visual oddities: when the `menu-bar-scrollbar'
> frame parameter has the value nil or `forced-resize' (or when the item
> "Menu Bar Scroll/Truncate" of the Options->Show/Hide menu is set to
> "Truncate" or "Resize Frame"), then there is no thin dividing line
> between the menu bar and the tool bar (in contrast to Emacs built
> without this patchset), and in addition, when a menu bar menu is open,
> the dividing lines in the menu are rather thick; but when the
> `menu-bar-scrollbar' frame parameter has the value `automatic', the thin
> dividing line between the menu bar and the tool bar is displayed (and
> the menu bar itself is noticeably thicker than in Emacs built without
> this patchset), and the dividing lines in an open menu are thinner,
> though not as thin as the line between the menu and tool bars (in Emacs
> built without this patchset the menu dividers are just as thin as the
> the divider between the menu and tool bars); with the parameter value
> `always' the scroll bar replaces the dividing line between the menu and
> tool bars, and the menu dividers have the same thickness as with the
> `automatic' setting.
I see none of these phenomenas with GTK 3.4.2 under xfce4. Just that
with 'always' and 'automatic' the menu bar has three times the height
of 'forced-resize' and has a 3D look absent with the latter. But GTK
3.4.2 is not really the target of Vivek's patch.
martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
[not found] ` <<835zxyqwtg.fsf@gnu.org>
@ 2018-10-20 23:58 ` Drew Adams
2018-10-21 2:39 ` Eli Zaretskii
0 siblings, 1 reply; 97+ messages in thread
From: Drew Adams @ 2018-10-20 23:58 UTC (permalink / raw)
To: Eli Zaretskii, Drew Adams; +Cc: 22000, vivek, deng
> > FWIW - AFAIK, it is not Emacs convention to add a blank line
> > between the first and second lines of text in a doc string.
>
> Quite a few of doc strings do leave an empty line there, and I find
> nothing wrong with that.
There are quite a few places in Emacs where things
are done in a less than ideal or conventional way.
Nothing-wrong versus room-for-improvement, perhaps.
FWIW, to me, *Help* output like this, for
`whitespace-toggle-option-alist', is less than ideal:
-----------------------------
Alist of toggle options.
Each element has the form:
(CHAR . SYMBOL)
Where:
CHAR is a char which the user will have to type.
SYMBOL is a valid symbol associated with CHAR.
See 'whitespace-style-value-list'.
-----------------------------
This is clearer, IMO:
-----------------------------
Alist of toggle options.
Each element has the form (CHAR . SYMBOL), where:
CHAR is a char which the user will have to type.
SYMBOL is a valid symbol associated with CHAR.
See `whitespace-style-value-list'.
-----------------------------
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-20 23:58 ` Drew Adams
@ 2018-10-21 2:39 ` Eli Zaretskii
0 siblings, 0 replies; 97+ messages in thread
From: Eli Zaretskii @ 2018-10-21 2:39 UTC (permalink / raw)
To: Drew Adams; +Cc: 22000, vivek, deng
> Date: Sat, 20 Oct 2018 16:58:37 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: vivek@etla.org, 22000@debbugs.gnu.org, deng@randomsample.de
>
> > > FWIW - AFAIK, it is not Emacs convention to add a blank line
> > > between the first and second lines of text in a doc string.
> >
> > Quite a few of doc strings do leave an empty line there, and I find
> > nothing wrong with that.
>
> There are quite a few places in Emacs where things
> are done in a less than ideal or conventional way.
> Nothing-wrong versus room-for-improvement, perhaps.
It's okay to think that style is not ideal, but please don't represent
the other style as our guidelines when they aren't. We should
distinguish between our personal opinions and the project's policy.
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-19 16:21 ` Stephen Berman
@ 2018-10-21 15:44 ` Vivek Dasmohapatra
2018-10-21 15:50 ` Vivek Dasmohapatra
1 sibling, 0 replies; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-21 15:44 UTC (permalink / raw)
To: Stephen Berman; +Cc: Robert Pluim, 22000
> Here's a screenshot showing the the menu and tool bars in Emacs without
> your patches (left), with patches and menu-bar-scrollbar set to
> `automatic' (middle) and set to nil (right):
This first height variation is not a glitch - when a scrollbar is present
('always) or could be present ('automatic) I have to let GTK reserve
some space for the scrollbar or the focus gets lost after certain
mouse interactions, at least until the user forces it back with a
particular widget interaction (which is very confusing as you
suddenly stop being able to type in any buffers or use the keyboard
to drive that instance of emacs).
When there's no scrollbar (nil) the extra space can be compressed away
with some CSS trickery (in theory the UI focus model is still broken, but
since there's no scrollbar to interact with the user can't start the bad
interaction sequence).
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-19 16:21 ` Stephen Berman
2018-10-21 15:44 ` Vivek Dasmohapatra
@ 2018-10-21 15:50 ` Vivek Dasmohapatra
2018-10-22 17:11 ` Vivek Dasmohapatra
1 sibling, 1 reply; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-21 15:50 UTC (permalink / raw)
To: Stephen Berman; +Cc: Robert Pluim, 22000
> Here's a screenshot showing the the menu and tool bars in Emacs without
> your patches (left), with patches and menu-bar-scrollbar set to
> `automatic' (middle) and set to nil (right):
I don't however, know what's up with the missing line or the gap
between the menu bar and the opened menu. I'll see if I can fix it
but the choice may be between one of:
- the current glitchy frame resize
- minor visual quirks like the missing line
- much larger (taller) menu bars (I don't know why GTK insists
on adding this much space, it's not something that seems
configurable except with CSS trickery)
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-21 15:50 ` Vivek Dasmohapatra
@ 2018-10-22 17:11 ` Vivek Dasmohapatra
0 siblings, 0 replies; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-22 17:11 UTC (permalink / raw)
To: Stephen Berman; +Cc: Robert Pluim, 22000
> - the current glitchy frame resize
>
> - minor visual quirks like the missing line
>
> - much larger (taller) menu bars (I don't know why GTK insists
Scrub all that, one of the gtk devs asked me a question which I think
has pointed me to the right answer. Updated patch to follow shortly.
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-19 17:57 ` martin rudalics
@ 2018-10-23 10:07 ` Robert Pluim
2018-10-23 13:45 ` martin rudalics
0 siblings, 1 reply; 97+ messages in thread
From: Robert Pluim @ 2018-10-23 10:07 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, vivek, Stephen Berman
[-- Attachment #1: Type: text/plain, Size: 1562 bytes --]
martin rudalics <rudalics@gmx.at> writes:
>> Further testing under KDE shows three things:
>>
>> 1. I get a vertical scrollbar on the right for the echo
>> area/minibuffer line but not the menubar using emacs -Q on
>> unmodified emacs-26, so that was not introduced by this patch
>
> Hmmm... Could you investigatte why this happens? Note that the echo
> area/minibuffer window by default hay a vertical scroll bar, just that
> it is hidden when the window height is less than the minimum length of
> the slider, see the following part of gtkutil.c:
>
> if (hidden)
> {
> /* No room. Hide scroll bar as some themes output a warning if
> the height is less than the min size. */
> gtk_widget_hide (wparent);
> gtk_widget_hide (wscroll);
> }
>
> If you put a breakpoint at the 'if' you should see what's different
> between GNOME and KDE.
Under KDE the minimum slider length is 21, under GNOME itʼs the same,
but the reported height of the echo area is > msl under KDE. This
looks like another scaling issue (except in this case the scale factor
reported by GTK is 1, so I can't do anything to fix it).
>> 2. In unmodified emacs-26, the line separating the menu bar from the
>> tool bar is solid, not dotted
>>
>> 3. I can get rid of the menu bar truncation issue by setting
>> margin-bottom to 10px
>
> When you do that does the spearator become solid again?
No, then I get both a solid separator and a dotted one just underneath
it:
[-- Attachment #2: Selection_046.png --]
[-- Type: image/png, Size: 12754 bytes --]
[-- Attachment #3: Type: text/plain, Size: 197 bytes --]
>> (but I still have the vertical scrollbar).
>
> Funny. I suppose that vertical menu bar scroll bar is of no use, that
> is, you don't get any truncated items in a second row?
Correct.
Robert
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-23 10:07 ` Robert Pluim
@ 2018-10-23 13:45 ` martin rudalics
2018-10-23 14:02 ` Robert Pluim
0 siblings, 1 reply; 97+ messages in thread
From: martin rudalics @ 2018-10-23 13:45 UTC (permalink / raw)
To: Robert Pluim; +Cc: 22000, vivek, Stephen Berman
> Under KDE the minimum slider length is 21, under GNOME itʼs the same,
> but the reported height of the echo area is > msl under KDE. This
> looks like another scaling issue (except in this case the scale factor
> reported by GTK is 1, so I can't do anything to fix it).
So which of the following interpretations is correct?
(1) The display artifacts happen regardless of whether scaling is
on or off.
(2) The display artifacts happen only when scaling is on.
(3) The display artifacts happen only when scaling is on and Emacs is
not aware of that fact because the reported scale factor is 1.
martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-23 13:45 ` martin rudalics
@ 2018-10-23 14:02 ` Robert Pluim
2018-10-23 18:18 ` martin rudalics
0 siblings, 1 reply; 97+ messages in thread
From: Robert Pluim @ 2018-10-23 14:02 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, vivek, Stephen Berman
martin rudalics <rudalics@gmx.at> writes:
>> Under KDE the minimum slider length is 21, under GNOME itʼs the same,
>> but the reported height of the echo area is > msl under KDE. This
>> looks like another scaling issue (except in this case the scale factor
>> reported by GTK is 1, so I can't do anything to fix it).
>
> So which of the following interpretations is correct?
>
> (1) The display artifacts happen regardless of whether scaling is
> on or off.
>
> (2) The display artifacts happen only when scaling is on.
>
> (3) The display artifacts happen only when scaling is on and Emacs is
> not aware of that fact because the reported scale factor is 1.
Itʼs (3). If I specifically run emacs with GDK_SCALE=2, then I see no
vertical scrollbar for the echo area, as expected.
Maybe I should just run GNOME all the time :-)
Robert
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-23 14:02 ` Robert Pluim
@ 2018-10-23 18:18 ` martin rudalics
2018-10-23 19:19 ` Robert Pluim
0 siblings, 1 reply; 97+ messages in thread
From: martin rudalics @ 2018-10-23 18:18 UTC (permalink / raw)
To: Robert Pluim; +Cc: 22000, vivek, Stephen Berman
>> (3) The display artifacts happen only when scaling is on and Emacs is
>> not aware of that fact because the reported scale factor is 1.
>
> Itʼs (3). If I specifically run emacs with GDK_SCALE=2, then I see no
> vertical scrollbar for the echo area, as expected.
In this case Vivek might not be the right addressee for this problem
because he probably does not scale. Provided the problem goes away
when you use 'forced-resize'. Otherwise, he should care.
martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-23 18:18 ` martin rudalics
@ 2018-10-23 19:19 ` Robert Pluim
2018-10-24 9:44 ` martin rudalics
0 siblings, 1 reply; 97+ messages in thread
From: Robert Pluim @ 2018-10-23 19:19 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, vivek, Stephen Berman
martin rudalics <rudalics@gmx.at> writes:
>>> (3) The display artifacts happen only when scaling is on and Emacs is
>>> not aware of that fact because the reported scale factor is 1.
>>
>> Itʼs (3). If I specifically run emacs with GDK_SCALE=2, then I see no
>> vertical scrollbar for the echo area, as expected.
>
> In this case Vivek might not be the right addressee for this problem
> because he probably does not scale. Provided the problem goes away
> when you use 'forced-resize'. Otherwise, he should care.
I donʼt understand how this could be Vivek's issue in any case: this
particular problem existed already in emacs-26.
Now the vertical scrollbar on the right of the menubar, *that* might
be Vivek's to solve (presumably thereʼs a need to tell the menubar
widget not to add that scrollbar).
Robert
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-23 19:19 ` Robert Pluim
@ 2018-10-24 9:44 ` martin rudalics
2018-10-24 11:52 ` Robert Pluim
0 siblings, 1 reply; 97+ messages in thread
From: martin rudalics @ 2018-10-24 9:44 UTC (permalink / raw)
To: Robert Pluim; +Cc: 22000, vivek, Stephen Berman
> I donʼt understand how this could be Vivek's issue in any case: this
> particular problem existed already in emacs-26.
I slowly begin to understand the issue. The vertical scroll bar shows
up as soon as the menu bar window gets high enough to make the slider
fit. Is that correct? One thing I do not understand then: Do we
really call xg_update_scrollbar_pos for the menu bar's scroll bar? If
so, how? IIUC the scroll bar code is oblivious to menu bar windows.
> Now the vertical scrollbar on the right of the menubar, *that* might
> be Vivek's to solve (presumably thereʼs a need to tell the menubar
> widget not to add that scrollbar).
Agreed.
martin
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-24 9:44 ` martin rudalics
@ 2018-10-24 11:52 ` Robert Pluim
2018-10-24 12:18 ` Vivek Dasmohapatra
0 siblings, 1 reply; 97+ messages in thread
From: Robert Pluim @ 2018-10-24 11:52 UTC (permalink / raw)
To: martin rudalics; +Cc: 22000, vivek, Stephen Berman
martin rudalics <rudalics@gmx.at> writes:
>> I donʼt understand how this could be Vivek's issue in any case: this
>> particular problem existed already in emacs-26.
>
> I slowly begin to understand the issue. The vertical scroll bar shows
> up as soon as the menu bar window gets high enough to make the slider
> fit. Is that correct? One thing I do not understand then: Do we
> really call xg_update_scrollbar_pos for the menu bar's scroll bar? If
> so, how? IIUC the scroll bar code is oblivious to menu bar windows.
>
The vertical scroll bar shows up immediately the menu bar is
drawn. xg_update_scrollbar_pos is not called for it at all. But see below.
>> Now the vertical scrollbar on the right of the menubar, *that* might
>> be Vivek's to solve (presumably thereʼs a need to tell the menubar
>> widget not to add that scrollbar).
>
> Agreed.
And in fact, after digging through some more GTK docs, itʼs as simple
as changing
gtk_scrolled_window_set_policy (sw, scroll_policy, GTK_POLICY_AUTOMATIC);
to
gtk_scrolled_window_set_policy (sw, scroll_policy, GTK_POLICY_NEVER);
in Vivek's patch. Vivek, does that make sense? I donʼt think we ever
want the menu bar to show a vertical scroll bar.
Note that this also fixes the visual glitch that I saw with the
dotted line and the menubar text descender truncation.
Regards
Robert
^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#22000: Patch addressing the menu-bar frame-resize interaction
2018-10-24 11:52 ` Robert Pluim
@ 2018-10-24 12:18 ` Vivek Dasmohapatra
0 siblings, 0 replies; 97+ messages in thread
From: Vivek Dasmohapatra @ 2018-10-24 12:18 UTC (permalink / raw)
To: Robert Pluim; +Cc: 22000, Stephen Berman
[-- Attachment #1: Type: TEXT/PLAIN, Size: 272 bytes --]
> And in fact, after digging through some more GTK docs, itʼs as simple
> as changing
>
> gtk_scrolled_window_set_policy (sw, scroll_policy, GTK_POLICY_AUTOMATIC);
>
Yes, I may be able to simplify the codepaths for earlier versions of GTK
too, currently testing that.
^ permalink raw reply [flat|nested] 97+ messages in thread
end of thread, other threads:[~2018-10-24 12:18 UTC | newest]
Thread overview: 97+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-23 20:55 bug#22000: 25.0.50; Running dired changes frame width, gtk_distribute_natural_allocation throws assertion David Engster
2015-11-24 8:28 ` martin rudalics
2015-11-24 16:48 ` David Engster
2015-11-24 19:26 ` martin rudalics
2015-11-25 16:15 ` David Engster
2015-11-25 17:48 ` martin rudalics
2015-11-25 19:00 ` David Engster
2015-11-26 8:22 ` martin rudalics
2018-07-15 18:09 ` bug#22000: Patch addressing the menu-bar frame-resize interaction Vivek Dasmohapatra
2018-07-16 7:28 ` martin rudalics
2018-07-16 9:46 ` Vivek Dasmohapatra
2018-07-16 19:58 ` Vivek Dasmohapatra
2018-07-17 7:48 ` martin rudalics
2018-07-17 13:45 ` Vivek Dasmohapatra
2018-07-17 19:02 ` Vivek Dasmohapatra
2018-07-18 7:01 ` martin rudalics
2018-07-18 7:07 ` martin rudalics
2018-07-18 10:39 ` Vivek Dasmohapatra
2018-07-19 8:19 ` martin rudalics
2018-07-19 12:04 ` Vivek Dasmohapatra
2018-07-20 8:14 ` martin rudalics
2018-07-20 9:21 ` Vivek Dasmohapatra
2018-07-20 12:34 ` martin rudalics
2018-07-20 17:44 ` Vivek Dasmohapatra
2018-07-21 7:43 ` martin rudalics
2018-07-21 13:24 ` Vivek Dasmohapatra
2018-07-22 7:24 ` martin rudalics
2018-07-22 12:29 ` Vivek Dasmohapatra
2018-07-23 6:50 ` martin rudalics
2018-10-11 13:05 ` Vivek Dasmohapatra
2018-10-11 18:17 ` martin rudalics
2018-10-11 18:27 ` martin rudalics
2018-10-11 18:48 ` Vivek Dasmohapatra
2018-10-11 20:51 ` Vivek Dasmohapatra
2018-10-12 8:44 ` martin rudalics
2018-10-12 12:47 ` Vivek Dasmohapatra
2018-10-12 18:12 ` martin rudalics
2018-10-12 18:25 ` Vivek Dasmohapatra
2018-10-13 8:20 ` martin rudalics
2018-10-13 10:03 ` Vivek Dasmohapatra
2018-10-15 13:57 ` Vivek Dasmohapatra
2018-10-15 18:23 ` martin rudalics
2018-10-16 1:19 ` Vivek Dasmohapatra
2018-10-16 8:47 ` martin rudalics
2018-10-16 18:58 ` Vivek Dasmohapatra
2018-10-17 7:29 ` martin rudalics
2018-10-18 1:02 ` Vivek Dasmohapatra
2018-10-18 8:06 ` martin rudalics
2018-10-18 12:23 ` Vivek Dasmohapatra
2018-10-18 12:48 ` Robert Pluim
2018-10-18 13:24 ` Vivek Dasmohapatra
2018-10-18 13:46 ` Robert Pluim
2018-10-18 13:56 ` Eli Zaretskii
2018-10-18 17:08 ` Vivek Dasmohapatra
2018-10-18 18:16 ` Eli Zaretskii
2018-10-18 18:34 ` Vivek Dasmohapatra
2018-10-18 13:51 ` Stephen Berman
2018-10-18 14:31 ` Robert Pluim
2018-10-18 13:51 ` Eli Zaretskii
2018-10-18 17:26 ` Vivek Dasmohapatra
2018-10-18 18:20 ` Eli Zaretskii
2018-10-18 18:32 ` Vivek Dasmohapatra
2018-10-18 19:55 ` Drew Adams
2018-10-19 6:23 ` Eli Zaretskii
2018-10-18 13:34 ` Eli Zaretskii
2018-10-18 14:22 ` Robert Pluim
2018-10-18 16:41 ` martin rudalics
2018-10-19 7:41 ` Robert Pluim
2018-10-19 8:34 ` martin rudalics
2018-10-19 9:14 ` Robert Pluim
2018-10-19 13:44 ` Robert Pluim
2018-10-19 17:57 ` martin rudalics
2018-10-23 10:07 ` Robert Pluim
2018-10-23 13:45 ` martin rudalics
2018-10-23 14:02 ` Robert Pluim
2018-10-23 18:18 ` martin rudalics
2018-10-23 19:19 ` Robert Pluim
2018-10-24 9:44 ` martin rudalics
2018-10-24 11:52 ` Robert Pluim
2018-10-24 12:18 ` Vivek Dasmohapatra
2018-10-19 14:17 ` Stephen Berman
2018-10-19 14:44 ` Vivek Dasmohapatra
2018-10-19 16:21 ` Stephen Berman
2018-10-21 15:44 ` Vivek Dasmohapatra
2018-10-21 15:50 ` Vivek Dasmohapatra
2018-10-22 17:11 ` Vivek Dasmohapatra
2018-10-19 17:57 ` martin rudalics
2018-10-18 16:40 ` martin rudalics
2018-10-18 17:07 ` Eli Zaretskii
2018-10-18 17:13 ` Vivek Dasmohapatra
2018-10-19 7:26 ` Robert Pluim
2018-10-19 8:23 ` Eli Zaretskii
2018-10-19 9:25 ` Robert Pluim
2018-10-12 18:34 ` Vivek Dasmohapatra
2018-10-12 18:16 ` Vivek Dasmohapatra
[not found] <<87k2p8h1vn.fsf@isaac.fritz.box>
[not found] ` <<5B52E425.8010608@gmx.at>
[not found] ` <<alpine.DEB.2.02.1807211421040.921@platypus.pepperfish.net>
[not found] ` <<5B543148.1010004@gmx.at>
[not found] ` <<alpine.DEB.2.02.1807221324380.921@platypus.pepperfish.net>
[not found] ` <<5B557ACA.4020106@gmx.at>
[not found] ` <<alpine.DEB.2.02.1810111400480.5980@platypus.pepperfish.net>
[not found] ` <<5BBF93CF.4060301@gmx.at>
[not found] ` <<alpine.DEB.2.02.1810112148100.5980@platypus.pepperfish.net>
[not found] ` <<5BC05EEB.9010609@gmx.at>
[not found] ` <<alpine.DEB.2.02.1810121316230.5980@platypus.pepperfish.net>
[not found] ` <<5BC0E405.90805@gmx.at>
[not found] ` <<alpine.DEB.2.02.1810121917570.5980@platypus.pepperfish.net>
[not found] ` <<5BC1AAE2.7070808@gmx.at>
[not found] ` <<alpine.DEB.2.02.1810151455060.19047@platypus.pepperfish.net>
[not found] ` <<5BC4DB0E.3050501@gmx.at>
[not found] ` <<alpine.DEB.2.02.1810161954120.19047@platypus.pepperfish.net>
[not found] ` <<5BC6E4F2.2030607@gmx.at>
[not found] ` <<alpine.DEB.2.02.1810180200180.19047@platypus.pepperfish.net>
[not found] ` <<5BC83F03.4050006@gmx.at>
[not found] ` <<alpine.DEB.2.02.1810181321230.19047@platypus.pepperfish.net>
[not found] ` <<83o9brqs6e.fsf@gnu.org>
[not found] ` <<alpine.DEB.2.02.1810181813500.19047@platypus.pepperfish.net>
[not found] ` <<83bm7rqfpo.fsf@gnu.org>
[not found] ` <<766dc2b9-7931-48b2-b2f2-6b57d7ca85dd@default>
[not found] ` <<835zxyqwtg.fsf@gnu.org>
2018-10-20 23:58 ` Drew Adams
2018-10-21 2:39 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).