GNU bug report logs -
#22000
25.0.50; Running dired changes frame width, gtk_distribute_natural_allocation throws assertion
Previous Next
To reply to this bug, email your comments to 22000 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Mon, 23 Nov 2015 20:56:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
David Engster <deng <at> randomsample.de>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 23 Nov 2015 20:56:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Tue, 24 Nov 2015 08:29:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> - 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Tue, 24 Nov 2015 16:49:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 22000 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[backtrace.txt (text/plain, inline)]
#0 g_log (log_domain=log_domain <at> entry=0x7ffff6db7edf "Gtk", log_level=log_level <at> entry=G_LOG_LEVEL_CRITICAL,
format=format <at> 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 <at> entry=0x7ffff6db7edf "Gtk",
pretty_function=pretty_function <at> entry=0x7ffff6e121c0 <__FUNCTION__.35024> "gtk_distribute_natural_allocation",
expression=expression <at> 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 <at> entry=0x1672600, return_value=0x8, return_value <at> entry=0x0, instance=0x7ffff5185e25,
instance <at> entry=0x199a400, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args <at> 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 <at> 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 <at> entry=0x1672600, return_value=0x8, return_value <at> entry=0x0, instance=0x7ffff5185e25,
instance <at> entry=0x7fffdc00a660, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args <at> 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 <at> 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 <at> entry=0x7fffdc00a660, allocation=allocation <at> 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 <at> entry=0x1603ee0, detail=detail <at> entry=0, instance=instance <at> entry=0x1996240,
emission_return=emission_return <at> entry=0x0, instance_and_params=instance_and_params <at> 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 <at> 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 <at> entry=0x1996240, allocation=allocation <at> 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 <at> entry=0x167b5c0, return_value=0x8, return_value <at> entry=0x0, instance=0x7ffff5185e25,
instance <at> entry=0x1996240, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args <at> 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 <at> 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 <at> entry=0x1e53780, return_value=0x8, return_value <at> entry=0x0, instance=0x7ffff5185e25,
instance <at> entry=0x170b250, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args <at> 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 <at> entry=0x170b250, detailed_signal=0x8 <error: Cannot access memory at address 0x8>,
detailed_signal <at> 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 <at> 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 <at> entry=0x16eacf0) at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3710
#37 0x00007ffff5134f48 in g_main_context_iterate (context=context <at> entry=0x16eacf0, block=block <at> entry=1, dispatch=dispatch <at> 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 <at> entry=0x0, may_block=may_block <at> 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
[backtrace_full.txt (text/plain, inline)]
bt full
#0 g_log (log_domain=log_domain <at> entry=0x7ffff6db7edf "Gtk", log_level=log_level <at> entry=G_LOG_LEVEL_CRITICAL,
format=format <at> 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 <at> entry=0x7ffff6db7edf "Gtk",
pretty_function=pretty_function <at> entry=0x7ffff6e121c0 <__FUNCTION__.35024> "gtk_distribute_natural_allocation",
expression=expression <at> 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 <at> entry=0x1672600, return_value=0x8, return_value <at> entry=0x0, instance=0x7ffff5185e25,
instance <at> entry=0x199a400, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args <at> 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 <at> 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 <at> entry=0x1672600, return_value=0x8, return_value <at> entry=0x0, instance=0x7ffff5185e25,
instance <at> entry=0x7fffdc00a660, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args <at> 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 <at> 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 <at> entry=0x7fffdc00a660, allocation=allocation <at> 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 <at> entry=0x1603ee0, detail=detail <at> entry=0, instance=instance <at> entry=0x1996240,
emission_return=emission_return <at> entry=0x0, instance_and_params=instance_and_params <at> 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 <at> 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 <at> entry=0x1996240, allocation=allocation <at> 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 <at> entry=0x167b5c0, return_value=0x8, return_value <at> entry=0x0, instance=0x7ffff5185e25,
instance <at> entry=0x1996240, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args <at> 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 <at> 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 <at> entry=0x1e53780, return_value=0x8, return_value <at> entry=0x0, instance=0x7ffff5185e25,
instance <at> entry=0x170b250, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args <at> 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 <at> entry=0x170b250, detailed_signal=0x8 <error: Cannot access memory at address 0x8>,
detailed_signal <at> 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 <at> 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 <at> 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 <at> entry=0x16eacf0, block=block <at> entry=1, dispatch=dispatch <at> 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 <at> entry=0x0, may_block=may_block <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Tue, 24 Nov 2015 19:27:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Wed, 25 Nov 2015 16:16:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 22000 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Wed, 25 Nov 2015 17:50:04 GMT)
Full text and
rfc822 format available.
Message #20 received at 22000 <at> debbugs.gnu.org (full text, mbox):
>> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Wed, 25 Nov 2015 19:01:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 22000 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 26 Nov 2015 08:24:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 22000 <at> debbugs.gnu.org (full text, mbox):
>> 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
Merged 15700 22000.
Request was from
martin rudalics <rudalics <at> gmx.at>
to
control <at> debbugs.gnu.org.
(Sun, 27 Dec 2015 15:55:01 GMT)
Full text and
rfc822 format available.
Removed tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Mon, 29 Feb 2016 05:34:03 GMT)
Full text and
rfc822 format available.
Forcibly Merged 15700 22000 22898.
Request was from
Lars Magne Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sun, 06 Mar 2016 09:36:02 GMT)
Full text and
rfc822 format available.
Merged 15700 22000 22898.
Request was from
martin rudalics <rudalics <at> gmx.at>
to
control <at> debbugs.gnu.org.
(Tue, 08 Mar 2016 08:04:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Sun, 15 Jul 2018 18:10:02 GMT)
Full text and
rfc822 format available.
Message #39 received at 22000 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
[0001-GTK3-menu-bars-force-frame-resizing-Bug-22000.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Mon, 16 Jul 2018 07:29:02 GMT)
Full text and
rfc822 format available.
Message #42 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Mon, 16 Jul 2018 09:48:01 GMT)
Full text and
rfc822 format available.
Message #45 received at 22000 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Mon, 16 Jul 2018 19:59:02 GMT)
Full text and
rfc822 format available.
Message #48 received at 22000 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
[0001-GTK3-menu-bars-force-frame-resizing-Bug-22000.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Tue, 17 Jul 2018 07:50:02 GMT)
Full text and
rfc822 format available.
Message #51 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Tue, 17 Jul 2018 13:46:02 GMT)
Full text and
rfc822 format available.
Message #54 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Tue, 17 Jul 2018 19:03:01 GMT)
Full text and
rfc822 format available.
Message #57 received at 22000 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> 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.
[0002-GTK3-correct-frame-height-calculation-with-scrollabl.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Wed, 18 Jul 2018 07:02:01 GMT)
Full text and
rfc822 format available.
Message #60 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Wed, 18 Jul 2018 07:08:01 GMT)
Full text and
rfc822 format available.
Message #63 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Wed, 18 Jul 2018 10:40:02 GMT)
Full text and
rfc822 format available.
Message #66 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 19 Jul 2018 08:20:01 GMT)
Full text and
rfc822 format available.
Message #69 received at 22000 <at> debbugs.gnu.org (full text, mbox):
>> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 19 Jul 2018 12:06:02 GMT)
Full text and
rfc822 format available.
Message #72 received at 22000 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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.
[gdb.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Fri, 20 Jul 2018 08:16:02 GMT)
Full text and
rfc822 format available.
Message #75 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Fri, 20 Jul 2018 09:22:01 GMT)
Full text and
rfc822 format available.
Message #78 received at 22000 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Fri, 20 Jul 2018 12:35:02 GMT)
Full text and
rfc822 format available.
Message #81 received at 22000 <at> debbugs.gnu.org (full text, mbox):
>> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Fri, 20 Jul 2018 17:45:02 GMT)
Full text and
rfc822 format available.
Message #84 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Sat, 21 Jul 2018 07:44:01 GMT)
Full text and
rfc822 format available.
Message #87 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Sat, 21 Jul 2018 13:25:01 GMT)
Full text and
rfc822 format available.
Message #90 received at 22000 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Sun, 22 Jul 2018 07:26:01 GMT)
Full text and
rfc822 format available.
Message #93 received at 22000 <at> debbugs.gnu.org (full text, mbox):
>> 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 ...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Sun, 22 Jul 2018 12:30:02 GMT)
Full text and
rfc822 format available.
Message #96 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Mon, 23 Jul 2018 06:52:01 GMT)
Full text and
rfc822 format available.
Message #99 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 11 Oct 2018 13:06:01 GMT)
Full text and
rfc822 format available.
Message #102 received at 22000 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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).
[emacs-frame-size-jitter.tar.xz (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 11 Oct 2018 18:19:01 GMT)
Full text and
rfc822 format available.
Message #105 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 11 Oct 2018 18:29:02 GMT)
Full text and
rfc822 format available.
Message #108 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> (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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 11 Oct 2018 18:49:02 GMT)
Full text and
rfc822 format available.
Message #111 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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 ?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 11 Oct 2018 20:52:01 GMT)
Full text and
rfc822 format available.
Message #114 received at 22000 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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.
[emacs-frame-size-jitter-5bd8cfc14d.tar.xz (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Fri, 12 Oct 2018 08:45:01 GMT)
Full text and
rfc822 format available.
Message #117 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Fri, 12 Oct 2018 12:49:02 GMT)
Full text and
rfc822 format available.
Message #120 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Fri, 12 Oct 2018 18:13:01 GMT)
Full text and
rfc822 format available.
Message #123 received at 22000 <at> debbugs.gnu.org (full text, mbox):
>> 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
...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Fri, 12 Oct 2018 18:17:02 GMT)
Full text and
rfc822 format available.
Message #126 received at 22000 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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.
[emacs-frame-size-jitter-compact.tar.xz (application/octet-stream, attachment)]
[menu-bar-comparison.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Fri, 12 Oct 2018 18:26:01 GMT)
Full text and
rfc822 format available.
Message #129 received at 22000 <at> debbugs.gnu.org (full text, mbox):
>> 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).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Fri, 12 Oct 2018 18:36:02 GMT)
Full text and
rfc822 format available.
Message #132 received at 22000 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Try adding this to the latest -compact series.
[0008-Manually-wrap-the-menu-bar-in-a-viewport-for-GTK-3.8.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Sat, 13 Oct 2018 08:22:02 GMT)
Full text and
rfc822 format available.
Message #135 received at 22000 <at> debbugs.gnu.org (full text, mbox):
>>> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Sat, 13 Oct 2018 10:04:02 GMT)
Full text and
rfc822 format available.
Message #138 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Mon, 15 Oct 2018 13:58:01 GMT)
Full text and
rfc822 format available.
Message #141 received at 22000 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 ]
[emacs-frame-size-jitter-rc0.tar.xz (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Mon, 15 Oct 2018 18:24:02 GMT)
Full text and
rfc822 format available.
Message #144 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Tue, 16 Oct 2018 01:20:02 GMT)
Full text and
rfc822 format available.
Message #147 received at 22000 <at> debbugs.gnu.org (full text, mbox):
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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Tue, 16 Oct 2018 08:48:02 GMT)
Full text and
rfc822 format available.
Message #150 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Tue, 16 Oct 2018 18:59:01 GMT)
Full text and
rfc822 format available.
Message #153 received at 22000 <at> debbugs.gnu.org (full text, mbox):
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_).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Wed, 17 Oct 2018 07:31:01 GMT)
Full text and
rfc822 format available.
Message #156 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 18 Oct 2018 01:03:02 GMT)
Full text and
rfc822 format available.
Message #159 received at 22000 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
New patch series - I think this has all the features and functionality
discussed so far.
[0001-GTK3-menu-bars-force-frame-resizing-Bug-22000.patch (text/x-diff, attachment)]
[0002-Document-the-new-menu-bar-scrollbar-frame-parameter.patch (text/x-diff, attachment)]
[0003-Hook-up-menu-bar-scrollbar-functionality-to-customiz.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 18 Oct 2018 08:07:01 GMT)
Full text and
rfc822 format available.
Message #162 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 18 Oct 2018 12:24:02 GMT)
Full text and
rfc822 format available.
Message #165 received at 22000 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
featurep guards added, defcustom setting emacs version bumped.
[0001-GTK3-menu-bars-force-frame-resizing-Bug-22000.patch (text/x-diff, attachment)]
[0002-Document-the-new-menu-bar-scrollbar-frame-parameter.patch (text/x-diff, attachment)]
[0003-Hook-up-menu-bar-scrollbar-functionality-to-customiz.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 18 Oct 2018 12:49:01 GMT)
Full text and
rfc822 format available.
Message #168 received at 22000 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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 <at> 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 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 18 Oct 2018 13:25:01 GMT)
Full text and
rfc822 format available.
Message #171 received at 22000 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 18 Oct 2018 13:36:03 GMT)
Full text and
rfc822 format available.
Message #174 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 18 Oct 2018 10:06:27 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 22000 <at> debbugs.gnu.org, David Engster <deng <at> randomsample.de>,
> "eliz <at> gnu.org" <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 18 Oct 2018 13:47:01 GMT)
Full text and
rfc822 format available.
Message #177 received at 22000 <at> debbugs.gnu.org (full text, mbox):
Vivek Dasmohapatra <vivek <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 18 Oct 2018 13:52:01 GMT)
Full text and
rfc822 format available.
Message #180 received at 22000 <at> debbugs.gnu.org (full text, mbox):
On Thu, 18 Oct 2018 14:48:21 +0200 Robert Pluim <rpluim <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 18 Oct 2018 13:53:02 GMT)
Full text and
rfc822 format available.
Message #183 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 18 Oct 2018 13:23:26 +0100 (BST)
> From: Vivek Dasmohapatra <vivek <at> etla.org>
> cc: 22000 <at> debbugs.gnu.org, David Engster <deng <at> randomsample.de>,
> "eliz <at> gnu.org" <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 18 Oct 2018 13:58:02 GMT)
Full text and
rfc822 format available.
Message #186 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 18 Oct 2018 14:24:14 +0100 (BST)
> From: Vivek Dasmohapatra <vivek <at> etla.org>
> Cc: 22000 <at> debbugs.gnu.org, David Engster <deng <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 18 Oct 2018 14:24:01 GMT)
Full text and
rfc822 format available.
Message #189 received at 22000 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Thu, 18 Oct 2018 10:06:27 +0200
>> From: martin rudalics <rudalics <at> gmx.at>
>> CC: 22000 <at> debbugs.gnu.org, David Engster <deng <at> randomsample.de>,
>> "eliz <at> gnu.org" <eliz <at> 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.
[Selection_045.png (image/png, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 18 Oct 2018 14:32:01 GMT)
Full text and
rfc822 format available.
Message #192 received at 22000 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> On Thu, 18 Oct 2018 14:48:21 +0200 Robert Pluim <rpluim <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 18 Oct 2018 16:42:02 GMT)
Full text and
rfc822 format available.
Message #195 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 18 Oct 2018 16:42:03 GMT)
Full text and
rfc822 format available.
Message #198 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 18 Oct 2018 17:08:01 GMT)
Full text and
rfc822 format available.
Message #201 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 18 Oct 2018 18:40:50 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: vivek <at> etla.org, 22000 <at> debbugs.gnu.org, deng <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 18 Oct 2018 17:09:02 GMT)
Full text and
rfc822 format available.
Message #204 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 18 Oct 2018 17:14:02 GMT)
Full text and
rfc822 format available.
Message #207 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 18 Oct 2018 17:27:01 GMT)
Full text and
rfc822 format available.
Message #210 received at 22000 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> +(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).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 18 Oct 2018 18:18:01 GMT)
Full text and
rfc822 format available.
Message #213 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 18 Oct 2018 18:08:42 +0100 (BST)
> From: Vivek Dasmohapatra <vivek <at> etla.org>
> cc: rpluim <at> gmail.com, 22000 <at> debbugs.gnu.org, deng <at> 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"?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 18 Oct 2018 18:22:01 GMT)
Full text and
rfc822 format available.
Message #216 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 18 Oct 2018 18:26:34 +0100 (BST)
> From: Vivek Dasmohapatra <vivek <at> etla.org>
> cc: rudalics <at> gmx.at, 22000 <at> debbugs.gnu.org, deng <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 18 Oct 2018 18:33:01 GMT)
Full text and
rfc822 format available.
Message #219 received at 22000 <at> debbugs.gnu.org (full text, mbox):
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?).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 18 Oct 2018 18:35:02 GMT)
Full text and
rfc822 format available.
Message #222 received at 22000 <at> debbugs.gnu.org (full text, mbox):
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Thu, 18 Oct 2018 19:56:01 GMT)
Full text and
rfc822 format available.
Message #225 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> (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.
..."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Fri, 19 Oct 2018 06:25:03 GMT)
Full text and
rfc822 format available.
Message #228 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 18 Oct 2018 12:55:09 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 22000 <at> debbugs.gnu.org, deng <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Fri, 19 Oct 2018 07:27:02 GMT)
Full text and
rfc822 format available.
Message #231 received at 22000 <at> debbugs.gnu.org (full text, mbox):
Vivek Dasmohapatra <vivek <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Fri, 19 Oct 2018 07:42:01 GMT)
Full text and
rfc822 format available.
Message #234 received at 22000 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Fri, 19 Oct 2018 08:25:02 GMT)
Full text and
rfc822 format available.
Message #237 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 22000 <at> debbugs.gnu.org, deng <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Fri, 19 Oct 2018 08:35:02 GMT)
Full text and
rfc822 format available.
Message #240 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Fri, 19 Oct 2018 09:16:02 GMT)
Full text and
rfc822 format available.
Message #243 received at 22000 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Fri, 19 Oct 2018 09:26:01 GMT)
Full text and
rfc822 format available.
Message #246 received at 22000 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 22000 <at> debbugs.gnu.org, deng <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Fri, 19 Oct 2018 13:45:02 GMT)
Full text and
rfc822 format available.
Message #249 received at 22000 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Fri, 19 Oct 2018 14:19:02 GMT)
Full text and
rfc822 format available.
Message #252 received at 22000 <at> debbugs.gnu.org (full text, mbox):
On Fri, 19 Oct 2018 10:34:08 +0200 martin rudalics <rudalics <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Fri, 19 Oct 2018 14:45:01 GMT)
Full text and
rfc822 format available.
Message #255 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Fri, 19 Oct 2018 16:22:01 GMT)
Full text and
rfc822 format available.
Message #258 received at 22000 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, 19 Oct 2018 15:44:21 +0100 (BST) Vivek Dasmohapatra <vivek <at> 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):
[menubar1.png (image/png, attachment)]
[Message part 3 (text/plain, inline)]
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:
[menubar2.png (image/png, attachment)]
[Message part 5 (text/plain, inline)]
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Fri, 19 Oct 2018 17:58:01 GMT)
Full text and
rfc822 format available.
Message #261 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Fri, 19 Oct 2018 17:58:02 GMT)
Full text and
rfc822 format available.
Message #264 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Sat, 20 Oct 2018 23:59:02 GMT)
Full text and
rfc822 format available.
Message #267 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> > 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'.
-----------------------------
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Sun, 21 Oct 2018 02:40:02 GMT)
Full text and
rfc822 format available.
Message #270 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 20 Oct 2018 16:58:37 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: vivek <at> etla.org, 22000 <at> debbugs.gnu.org, deng <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Sun, 21 Oct 2018 15:45:02 GMT)
Full text and
rfc822 format available.
Message #273 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Sun, 21 Oct 2018 15:51:02 GMT)
Full text and
rfc822 format available.
Message #276 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Mon, 22 Oct 2018 17:12:01 GMT)
Full text and
rfc822 format available.
Message #279 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> - 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Tue, 23 Oct 2018 10:08:01 GMT)
Full text and
rfc822 format available.
Message #282 received at 22000 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
martin rudalics <rudalics <at> 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:
[Selection_046.png (image/png, inline)]
[Message part 3 (text/plain, inline)]
>> (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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Tue, 23 Oct 2018 13:46:02 GMT)
Full text and
rfc822 format available.
Message #285 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Tue, 23 Oct 2018 14:03:03 GMT)
Full text and
rfc822 format available.
Message #288 received at 22000 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Tue, 23 Oct 2018 18:19:01 GMT)
Full text and
rfc822 format available.
Message #291 received at 22000 <at> debbugs.gnu.org (full text, mbox):
>> (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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Tue, 23 Oct 2018 19:20:02 GMT)
Full text and
rfc822 format available.
Message #294 received at 22000 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Wed, 24 Oct 2018 09:45:01 GMT)
Full text and
rfc822 format available.
Message #297 received at 22000 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Wed, 24 Oct 2018 11:53:02 GMT)
Full text and
rfc822 format available.
Message #300 received at 22000 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22000; Package
emacs.
(Wed, 24 Oct 2018 12:19:02 GMT)
Full text and
rfc822 format available.
Message #303 received at 22000 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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.
This bug report was last modified 5 years and 266 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.