bug#22000: 25.0.50; Running dired changes frame width, gtk_distribute_natural_allocation throws assertion

bug#22000: 25.0.50; Running dired changes frame width, gtk_distribute_natural_allocation throws assertion

[David Engster]

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

bug#22000: 25.0.50; Running dired changes frame width, gtk_distribute_natural_allocation throws assertion

[martin rudalics]

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

bug#22000: 25.0.50; Running dired changes frame width, gtk_distribute_natural_allocation throws assertion

[David Engster]

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

martin rudalics writes:
>> - In the console output, I see
>>
>>    (emacs:27459): Gtk-CRITICAL **:
>> gtk_distribute_natural_allocation: assertion 'extra_space >= 0'
>> failed
>>
>> - I also see this assertion when I resize the frame with the mouse to a
>>    smaller width than those 78 characters.
>
> Does it also happen with ‘frame-resize-pixelwise’ non-nil?

Yes. But at least I know now what really triggers this problem: GTK
throws this assertion when the menubar is not completely visible. This
is also why running Dired triggers this, because it adds a bunch of
additional menu entries. The frame is then resized so that the menu-bar
fits.

I also have to correct myself: The font doesn't seem to have anything to
do with it; it also happens with Bitmap fonts, it was just by chance
that this configuration had the menu-bar disabled.

I realized that the menu-bar is the reason by putting a breakpoint into
g_log through which the assertion is displayed, and you see that
gtk_menu_bar_size_allocate is actually triggering this. I attached the
full and normal backtrace to this file (xbacktrace is empty).

-David


[-- Attachment #2: backtrace.txt --]
[-- Type: text/plain, Size: 10886 bytes --]

#0  g_log (log_domain=log_domain@entry=0x7ffff6db7edf "Gtk", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, 
    format=format@entry=0x7ffff5185e25 "%s: assertion '%s' failed") at /tmp/buildd/glib2.0-2.42.1/./glib/gmessages.c:1075
#1  0x00007ffff513bfa9 in g_return_if_fail_warning (log_domain=log_domain@entry=0x7ffff6db7edf "Gtk", 
    pretty_function=pretty_function@entry=0x7ffff6e121c0 <__FUNCTION__.35024> "gtk_distribute_natural_allocation", 
    expression=expression@entry=0x7ffff6e11e07 "extra_space >= 0") at /tmp/buildd/glib2.0-2.42.1/./glib/gmessages.c:1088
#2  0x00007ffff6cb685a in gtk_distribute_natural_allocation (extra_space=-9, n_requested_sizes=<optimized out>, sizes=<optimized out>)
    at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtksizerequest.c:801
#3  0x00007ffff6c45828 in gtk_menu_bar_size_allocate (widget=<optimized out>, allocation=<optimized out>) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkmenubar.c:544
#4  0x00007ffff540d233 in g_cclosure_marshal_VOID__BOXEDv (closure=0x1672600, return_value=<optimized out>, instance=<optimized out>, args=<optimized out>, 
    marshal_data=<optimized out>, n_params=<optimized out>, param_types=0x1603f50) at /tmp/buildd/glib2.0-2.42.1/./gobject/gmarshal.c:1160
#5  0x00007ffff540a3c2 in _g_closure_invoke_va (closure=0x7ffff6db7edf, closure@entry=0x1672600, return_value=0x8, return_value@entry=0x0, instance=0x7ffff5185e25, 
    instance@entry=0x199a400, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args@entry=0x7fffffffb9e0, n_params=-153018873, param_types=0x1682470)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:831
#6  0x00007ffff5424087 in g_signal_emit_valist (instance=0x199a400, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffb9e0)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3218
#7  0x00007ffff54249df in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3365
#8  0x00007ffff6d67de7 in gtk_widget_size_allocate_with_baseline (widget=0x199a400, allocation=0x0, baseline=-1) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwidget.c:6075
#9  0x00007ffff6b3e21d in gtk_box_size_allocate_no_center (widget=0x7fffdc00a660, allocation=0x7fffffffc050) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkbox.c:800
#10 0x00007ffff540d233 in g_cclosure_marshal_VOID__BOXEDv (closure=0x1672600, return_value=<optimized out>, instance=<optimized out>, args=<optimized out>, 
    marshal_data=<optimized out>, n_params=<optimized out>, param_types=0x1603f50) at /tmp/buildd/glib2.0-2.42.1/./gobject/gmarshal.c:1160
#11 0x00007ffff540a3c2 in _g_closure_invoke_va (closure=0x7ffff6db7edf, closure@entry=0x1672600, return_value=0x8, return_value@entry=0x0, instance=0x7ffff5185e25, 
    instance@entry=0x7fffdc00a660, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args@entry=0x7fffffffbf10, n_params=-153018873, param_types=0x1682470)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:831
#12 0x00007ffff5424087 in g_signal_emit_valist (instance=0x7fffdc00a660, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffbf10)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3218
#13 0x00007ffff54249df in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3365
#14 0x00007ffff6d67de7 in gtk_widget_size_allocate_with_baseline (widget=0x7fffdc00a660, allocation=0x0, baseline=-1)
    at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwidget.c:6075
#15 0x00007ffff6d681aa in gtk_widget_size_allocate (widget=widget@entry=0x7fffdc00a660, allocation=allocation@entry=0x7fffffffc0d0)
    at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwidget.c:6151
#16 0x00007ffff6d7e4d3 in gtk_window_size_allocate (widget=<optimized out>, allocation=<optimized out>) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwindow.c:7309
#17 0x00007ffff540a245 in g_closure_invoke (closure=0x1672600, return_value=0x0, n_param_values=2, param_values=0x7fffffffc2d0, invocation_hint=0x7fffffffc270)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:768
#18 0x00007ffff541b83b in signal_emit_unlocked_R (node=node@entry=0x1603ee0, detail=detail@entry=0, instance=instance@entry=0x1996240, 
    emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffc2d0) at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3483
#19 0x00007ffff5424778 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffc460)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3309
#20 0x00007ffff54249df in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3365
#21 0x00007ffff6d67de7 in gtk_widget_size_allocate_with_baseline (widget=0x1996240, allocation=0x0, baseline=-1) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwidget.c:6075
#22 0x00007ffff6d681aa in gtk_widget_size_allocate (widget=widget@entry=0x1996240, allocation=allocation@entry=0x7fffffffc690)
    at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwidget.c:6151
#23 0x00007ffff6d78811 in gtk_window_move_resize (window=0x1996240) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwindow.c:9147
#24 gtk_window_check_resize (container=0x1996240) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwindow.c:7916
#25 0x00007ffff540a474 in _g_closure_invoke_va (closure=0x7ffff6db7edf, closure@entry=0x167b5c0, return_value=0x8, return_value@entry=0x0, instance=0x7ffff5185e25, 
    instance@entry=0x1996240, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args@entry=0x7fffffffc900, n_params=-153018873, param_types=0x1682470)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:831
---Type <return> to continue, or q <return> to quit---
#26 0x00007ffff5424087 in g_signal_emit_valist (instance=0x1996240, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffc900)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3218
#27 0x00007ffff54249df in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3365
#28 0x00007ffff6b821fc in gtk_container_idle_sizer (clock=0x170b250, container=0x1996240) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkcontainer.c:1755
#29 0x00007ffff540a474 in _g_closure_invoke_va (closure=0x7ffff6db7edf, closure@entry=0x1e53780, return_value=0x8, return_value@entry=0x0, instance=0x7ffff5185e25, 
    instance@entry=0x170b250, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args@entry=0x7fffffffcc48, n_params=-153018873, param_types=0x1682470)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:831
#30 0x00007ffff5424087 in g_signal_emit_valist (instance=0x170b250, signal_id=<optimized out>, detail=0, var_args=0x7fffffffcc48)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3218
#31 0x00007ffff5424f2a in g_signal_emit_by_name (instance=0x7ffff6db7edf, instance@entry=0x170b250, detailed_signal=0x8 <error: Cannot access memory at address 0x8>, 
    detailed_signal@entry=0x7ffff681b736 "layout") at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3405
#32 0x00007ffff67b5974 in gdk_frame_clock_paint_idle (data=0x170b250) at /tmp/buildd/gtk+3.0-3.14.5/./gdk/gdkframeclockidle.c:408
#33 0x00007ffff67a7e78 in gdk_threads_dispatch (data=0x1860b40, data@entry=<error reading variable: value has been optimized out>)
    at /tmp/buildd/gtk+3.0-3.14.5/./gdk/gdk.c:654
#34 0x00007ffff5135613 in g_timeout_dispatch (source=0x1e58820, callback=<optimized out>, user_data=<optimized out>) at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:4520
#35 0x00007ffff5134b6d in g_main_dispatch (context=0x16eacf0) at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3111
#36 g_main_context_dispatch (context=context@entry=0x16eacf0) at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3710
#37 0x00007ffff5134f48 in g_main_context_iterate (context=context@entry=0x16eacf0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3781
#38 0x00007ffff5134ffc in g_main_context_iteration (context=0x16eacf0, context@entry=0x0, may_block=may_block@entry=1) at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3842
#39 0x00007ffff6c2dcc5 in gtk_main_iteration () at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkmain.c:1308
#40 0x0000000000545c63 in XTread_socket (terminal=0x12fdb80, hold_quit=0x7fffffffcf60) at xterm.c:8775
#41 0x0000000000592262 in gobble_input () at keyboard.c:6771
#42 0x00000000005927e7 in handle_async_input () at keyboard.c:7023
#43 0x0000000000592806 in process_pending_signals () at keyboard.c:7037
#44 0x0000000000604c49 in Fmake_list (length=0, init=0) at alloc.c:2705
#45 0x00000000006361fb in concat (nargs=1, args=0x7fffffffd1a8, target_type=Lisp_Cons, last_special=false) at fns.c:633
#46 0x0000000000635b9a in Fcopy_sequence (arg=22459043) at fns.c:501
#47 0x000000000058c928 in timer_check () at keyboard.c:4447
#48 0x000000000058a0f6 in readable_events (flags=1) at keyboard.c:3304
#49 0x00000000005920ac in get_input_pending (flags=1) at keyboard.c:6686
#50 0x0000000000599894 in detect_input_pending_run_timers (do_display=true) at keyboard.c:9817
#51 0x000000000068a0db in wait_reading_process_output (time_limit=0, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=0, wait_proc=0x0, just_wait_proc=0)
    at process.c:4963
#52 0x000000000058b16c in kbd_buffer_get_event (kbp=0x7fffffffd818, used_mouse_menu=0x7fffffffddff, end_time=0x0) at keyboard.c:3795
#53 0x0000000000586701 in read_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffffdbc0, used_mouse_menu=0x7fffffffddff) at keyboard.c:2121
#54 0x00000000005869d0 in read_decoded_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffffdbc0, prev_event=0, used_mouse_menu=0x7fffffffddff)
    at keyboard.c:2184
#55 0x000000000058863c in read_char (commandflag=1, map=30806627, prev_event=0, used_mouse_menu=0x7fffffffddff, end_time=0x0) at keyboard.c:2779
#56 0x0000000000597c93 in read_key_sequence (keybuf=0x7fffffffdfb0, bufsize=30, prompt=0, dont_downcase_last=false, can_return_switch_frame=true, 
    fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9018
#57 0x00000000005846af in command_loop_1 () at keyboard.c:1343
#58 0x000000000062d0e3 in internal_condition_case (bfun=0x58426d <command_loop_1>, handlers=18912, hfun=0x5838db <cmd_error>) at eval.c:1309
#59 0x0000000000583e9b in command_loop_2 (ignore=0) at keyboard.c:1086
#60 0x000000000062c68d in internal_catch (tag=45696, func=0x583e72 <command_loop_2>, arg=0) at eval.c:1074
#61 0x0000000000583e3b in command_loop () at keyboard.c:1065
#62 0x00000000005833ba in recursive_edit_1 () at keyboard.c:671
#63 0x00000000005835c5 in Frecursive_edit () at keyboard.c:742
---Type <return> to continue, or q <return> to quit---
#64 0x00000000005813d8 in main (argc=2, argv=0x7fffffffe438) at emacs.c:1656

[-- Attachment #3: backtrace_full.txt --]
[-- Type: text/plain, Size: 36129 bytes --]

bt full
#0  g_log (log_domain=log_domain@entry=0x7ffff6db7edf "Gtk", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, 
    format=format@entry=0x7ffff5185e25 "%s: assertion '%s' failed") at /tmp/buildd/glib2.0-2.42.1/./glib/gmessages.c:1075
        args = {{
            gp_offset = 0, 
            fp_offset = 0, 
            overflow_arg_area = 0x1631580, 
            reg_save_area = 0x7fffffffb600
          }}
#1  0x00007ffff513bfa9 in g_return_if_fail_warning (log_domain=log_domain@entry=0x7ffff6db7edf "Gtk", 
    pretty_function=pretty_function@entry=0x7ffff6e121c0 <__FUNCTION__.35024> "gtk_distribute_natural_allocation", 
    expression=expression@entry=0x7ffff6e11e07 "extra_space >= 0") at /tmp/buildd/glib2.0-2.42.1/./glib/gmessages.c:1088
No locals.
#2  0x00007ffff6cb685a in gtk_distribute_natural_allocation (extra_space=-9, n_requested_sizes=<optimized out>, sizes=<optimized out>)
    at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtksizerequest.c:801
        spreading = <optimized out>
        i = <optimized out>
        __FUNCTION__ = "gtk_distribute_natural_allocation"
#3  0x00007ffff6c45828 in gtk_menu_bar_size_allocate (widget=<optimized out>, allocation=<optimized out>) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkmenubar.c:544
        size = <optimized out>
        ltr = 1
        context = <optimized out>
        flags = <optimized out>
        border = {
          left = 0, 
          right = 0, 
          top = 0, 
          bottom = 0
        }
        menu_bar = <optimized out>
        menu_shell = <optimized out>
        priv = <optimized out>
        child = <optimized out>
        children = <optimized out>
        remaining_space = {
          x = 0, 
          y = <optimized out>, 
          width = 443, 
          height = 24
        }
        border_width = <optimized out>
        requested_sizes = 0xe53090
        toggle_size = 0
        i = <optimized out>
        __FUNCTION__ = "gtk_menu_bar_size_allocate"
#4  0x00007ffff540d233 in g_cclosure_marshal_VOID__BOXEDv (closure=0x1672600, return_value=<optimized out>, instance=<optimized out>, args=<optimized out>, 
    marshal_data=<optimized out>, n_params=<optimized out>, param_types=0x1603f50) at /tmp/buildd/glib2.0-2.42.1/./gobject/gmarshal.c:1160
        cc = 0x1672600
        data1 = <optimized out>
        data2 = <optimized out>
---Type <return> to continue, or q <return> to quit---
        callback = <optimized out>
        arg0 = 0x7fffffffbb20
        args_copy = {{
            gp_offset = 32, 
            fp_offset = 48, 
            overflow_arg_area = 0x7fffffffbac0, 
            reg_save_area = 0x7fffffffba00
          }}
#5  0x00007ffff540a3c2 in _g_closure_invoke_va (closure=0x7ffff6db7edf, closure@entry=0x1672600, return_value=0x8, return_value@entry=0x0, instance=0x7ffff5185e25, 
    instance@entry=0x199a400, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args@entry=0x7fffffffb9e0, n_params=-153018873, param_types=0x1682470)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:831
        marshal = 0x0
        marshal_data = 0x7ffff6e11e07
        __FUNCTION__ = "_g_closure_invoke_va"
#6  0x00007ffff5424087 in g_signal_emit_valist (instance=0x199a400, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffb9e0)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3218
        return_accu = <optimized out>
        accu = {
          g_type = 0, 
          data = {{
              v_int = 0, 
              v_uint = 0, 
              v_long = 0, 
              v_ulong = 0, 
              v_int64 = 0, 
              v_uint64 = 0, 
              v_float = 0, 
              v_double = 0, 
              v_pointer = 0x0
            }, {
              v_int = 0, 
              v_uint = 0, 
              v_long = 0, 
              v_ulong = 0, 
              v_int64 = 0, 
              v_uint64 = 0, 
              v_float = 0, 
              v_double = 0, 
              v_pointer = 0x0
            }}
        }
        accumulator = 0x0
        emission = {
          next = 0x7fffffffbe50, 
          instance = 0x199a400, 
          ihint = {
            signal_id = 10, 
            detail = 0, 
            run_type = G_SIGNAL_RUN_FIRST
---Type <return> to continue, or q <return> to quit---
          }, 
          state = EMISSION_RUN, 
          chain_type = 24923888
        }
        signal_id = 10
        instance_type = <optimized out>
        emission_return = {
          g_type = 0, 
          data = {{
              v_int = 0, 
              v_uint = 0, 
              v_long = 0, 
              v_ulong = 0, 
              v_int64 = 0, 
              v_uint64 = 0, 
              v_float = 0, 
              v_double = 0, 
              v_pointer = 0x0
            }, {
              v_int = 0, 
              v_uint = 0, 
              v_long = 0, 
              v_ulong = 0, 
              v_int64 = 0, 
              v_uint64 = 0, 
              v_float = 0, 
              v_double = 0, 
              v_pointer = 0x0
            }}
        }
        rtype = 4
        static_scope = 0
        fastpath_handler = <optimized out>
        closure = 0x1672600
        run_type = <optimized out>
        l = <optimized out>
        fastpath = <optimized out>
        instance_and_params = <optimized out>
        signal_return_type = <optimized out>
        param_values = <optimized out>
        i = <optimized out>
        n_params = <optimized out>
        __FUNCTION__ = "g_signal_emit_valist"
#7  0x00007ffff54249df in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3365
        var_args = {{
            gp_offset = 24, 
            fp_offset = 48, 
            overflow_arg_area = 0x7fffffffbac0, 
---Type <return> to continue, or q <return> to quit---
            reg_save_area = 0x7fffffffba00
          }}
#8  0x00007ffff6d67de7 in gtk_widget_size_allocate_with_baseline (widget=0x199a400, allocation=0x0, baseline=-1) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwidget.c:6075
        priv = 0x199a320
        real_allocation = {
          x = 0, 
          y = 0, 
          width = 443, 
          height = 24
        }
        old_clip = {
          x = 0, 
          y = 0, 
          width = 452, 
          height = 24
        }
        adjusted_allocation = {
          x = 0, 
          y = 0, 
          width = 443, 
          height = 24
        }
        size_changed = 1
        baseline_changed = 0
        position_changed = 0
        natural_width = 452
        natural_height = 24
        dummy = 32767
        min_width = 452
        min_height = 24
        __FUNCTION__ = "gtk_widget_size_allocate_with_baseline"
#9  0x00007ffff6b3e21d in gtk_box_size_allocate_no_center (widget=0x7fffdc00a660, allocation=0x7fffffffc050) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkbox.c:800
        box = 0x7fffdc00a660
        private = 0x7fffdc00a540
        child = 0x1b05480
        children = 0x18512c0
        nvis_children = 3
        nexpand_children = 1
        direction = GTK_TEXT_DIR_LTR
        child_allocation = {
          x = 0, 
          y = 0, 
          width = 443, 
          height = 24
        }
        sizes = 0x7fffffffbba0
        child_minimum_baseline = 0
        child_natural_baseline = 0
        minimum_above = <optimized out>
---Type <return> to continue, or q <return> to quit---
        natural_above = <optimized out>
        minimum_below = <optimized out>
        natural_below = <optimized out>
        have_baseline = <optimized out>
        baseline = -1
        packing = GTK_PACK_START
        size = <optimized out>
        extra = <optimized out>
        n_extra_widgets = <optimized out>
        x = 0
        y = 24
        i = 0
        child_size = <optimized out>
#10 0x00007ffff540d233 in g_cclosure_marshal_VOID__BOXEDv (closure=0x1672600, return_value=<optimized out>, instance=<optimized out>, args=<optimized out>, 
    marshal_data=<optimized out>, n_params=<optimized out>, param_types=0x1603f50) at /tmp/buildd/glib2.0-2.42.1/./gobject/gmarshal.c:1160
        cc = 0x1672600
        data1 = <optimized out>
        data2 = <optimized out>
        callback = <optimized out>
        arg0 = 0x7fffffffc050
        args_copy = {{
            gp_offset = 32, 
            fp_offset = 48, 
            overflow_arg_area = 0x7fffffffbff0, 
            reg_save_area = 0x7fffffffbf30
          }}
#11 0x00007ffff540a3c2 in _g_closure_invoke_va (closure=0x7ffff6db7edf, closure@entry=0x1672600, return_value=0x8, return_value@entry=0x0, instance=0x7ffff5185e25, 
    instance@entry=0x7fffdc00a660, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args@entry=0x7fffffffbf10, n_params=-153018873, param_types=0x1682470)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:831
        marshal = 0x0
        marshal_data = 0x7ffff6e11e07
        __FUNCTION__ = "_g_closure_invoke_va"
#12 0x00007ffff5424087 in g_signal_emit_valist (instance=0x7fffdc00a660, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffbf10)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3218
        return_accu = <optimized out>
        accu = {
          g_type = 0, 
          data = {{
              v_int = 0, 
              v_uint = 0, 
              v_long = 0, 
              v_ulong = 0, 
              v_int64 = 0, 
              v_uint64 = 0, 
              v_float = 0, 
              v_double = 0, 
              v_pointer = 0x0
            }, {
              v_int = 0, 
---Type <return> to continue, or q <return> to quit---
              v_uint = 0, 
              v_long = 0, 
              v_ulong = 0, 
              v_int64 = 0, 
              v_uint64 = 0, 
              v_float = 0, 
              v_double = 0, 
              v_pointer = 0x0
            }}
        }
        accumulator = 0x0
        emission = {
          next = 0x7fffffffc260, 
          instance = 0x7fffdc00a660, 
          ihint = {
            signal_id = 10, 
            detail = 0, 
            run_type = G_SIGNAL_RUN_FIRST
          }, 
          state = EMISSION_RUN, 
          chain_type = 26249584
        }
        signal_id = 10
        instance_type = <optimized out>
        emission_return = {
          g_type = 0, 
          data = {{
              v_int = 0, 
              v_uint = 0, 
              v_long = 0, 
              v_ulong = 0, 
              v_int64 = 0, 
              v_uint64 = 0, 
              v_float = 0, 
              v_double = 0, 
              v_pointer = 0x0
            }, {
              v_int = 0, 
              v_uint = 0, 
              v_long = 0, 
              v_ulong = 0, 
              v_int64 = 0, 
              v_uint64 = 0, 
              v_float = 0, 
              v_double = 0, 
              v_pointer = 0x0
            }}
        }
        rtype = 4
---Type <return> to continue, or q <return> to quit---
        static_scope = 0
        fastpath_handler = <optimized out>
        closure = 0x1672600
        run_type = <optimized out>
        l = <optimized out>
        fastpath = <optimized out>
        instance_and_params = <optimized out>
        signal_return_type = <optimized out>
        param_values = <optimized out>
        i = <optimized out>
        n_params = <optimized out>
        __FUNCTION__ = "g_signal_emit_valist"
#13 0x00007ffff54249df in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3365
        var_args = {{
            gp_offset = 24, 
            fp_offset = 48, 
            overflow_arg_area = 0x7fffffffbff0, 
            reg_save_area = 0x7fffffffbf30
          }}
#14 0x00007ffff6d67de7 in gtk_widget_size_allocate_with_baseline (widget=0x7fffdc00a660, allocation=0x0, baseline=-1)
    at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwidget.c:6075
        priv = 0x7fffdc00a580
        real_allocation = {
          x = 0, 
          y = 0, 
          width = 443, 
          height = 627
        }
        old_clip = {
          x = 0, 
          y = 0, 
          width = 452, 
          height = 627
        }
        adjusted_allocation = {
          x = 0, 
          y = 0, 
          width = 443, 
          height = 627
        }
        size_changed = 1
        baseline_changed = 0
        position_changed = 0
        natural_width = 533
        natural_height = 156
        dummy = 32767
        min_width = 452
        min_height = 156
---Type <return> to continue, or q <return> to quit---
        __FUNCTION__ = "gtk_widget_size_allocate_with_baseline"
#15 0x00007ffff6d681aa in gtk_widget_size_allocate (widget=widget@entry=0x7fffdc00a660, allocation=allocation@entry=0x7fffffffc0d0)
    at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwidget.c:6151
No locals.
#16 0x00007ffff6d7e4d3 in gtk_window_size_allocate (widget=<optimized out>, allocation=<optimized out>) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwindow.c:7309
        window = <optimized out>
        child = 0x7fffdc00a660
        child_allocation = {
          x = 0, 
          y = 0, 
          width = 443, 
          height = 627
        }
#17 0x00007ffff540a245 in g_closure_invoke (closure=0x1672600, return_value=0x0, n_param_values=2, param_values=0x7fffffffc2d0, invocation_hint=0x7fffffffc270)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:768
        marshal = <optimized out>
        marshal_data = <optimized out>
        in_marshal = 0
        real_closure = 0x16725e0
        __FUNCTION__ = "g_closure_invoke"
#18 0x00007ffff541b83b in signal_emit_unlocked_R (node=node@entry=0x1603ee0, detail=detail@entry=0, instance=instance@entry=0x1996240, 
    emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffc2d0) at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3483
        accumulator = 0x0
        emission = {
          next = 0x7fffffffc840, 
          instance = 0x1996240, 
          ihint = {
            signal_id = 10, 
            detail = 0, 
            run_type = G_SIGNAL_RUN_FIRST
          }, 
          state = EMISSION_RUN, 
          chain_type = 23647328
        }
        handler_list = <optimized out>
        return_accu = 0x0
        accu = {
          g_type = 0, 
          data = {{
              v_int = 0, 
              v_uint = 0, 
              v_long = 0, 
              v_ulong = 0, 
              v_int64 = 0, 
              v_uint64 = 0, 
              v_float = 0, 
              v_double = 0, 
              v_pointer = 0x0
            }, {
---Type <return> to continue, or q <return> to quit---
              v_int = 0, 
              v_uint = 0, 
              v_long = 0, 
              v_ulong = 0, 
              v_int64 = 0, 
              v_uint64 = 0, 
              v_float = 0, 
              v_double = 0, 
              v_pointer = 0x0
            }}
        }
        signal_id = 10
        max_sequential_handler_number = 11502
        return_value_altered = <optimized out>
#19 0x00007ffff5424778 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffc460)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3309
        instance_and_params = 0x7fffffffc2d0
        signal_return_type = <optimized out>
        param_values = 0x7fffffffc2e8
        i = <optimized out>
        n_params = <optimized out>
        __FUNCTION__ = "g_signal_emit_valist"
#20 0x00007ffff54249df in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3365
        var_args = {{
            gp_offset = 32, 
            fp_offset = 48, 
            overflow_arg_area = 0x7fffffffc540, 
            reg_save_area = 0x7fffffffc480
          }}
#21 0x00007ffff6d67de7 in gtk_widget_size_allocate_with_baseline (widget=0x1996240, allocation=0x0, baseline=-1) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwidget.c:6075
        priv = 0x1996160
        real_allocation = {
          x = 0, 
          y = 0, 
          width = 443, 
          height = 627
        }
        old_clip = {
          x = 0, 
          y = 0, 
          width = 452, 
          height = 627
        }
        adjusted_allocation = {
          x = 0, 
          y = 0, 
          width = 443, 
          height = 627
---Type <return> to continue, or q <return> to quit---
        }
        size_changed = 1
        baseline_changed = 0
        position_changed = 0
        natural_width = 533
        natural_height = 156
        dummy = -388717296
        min_width = 452
        min_height = 156
        __FUNCTION__ = "gtk_widget_size_allocate_with_baseline"
#22 0x00007ffff6d681aa in gtk_widget_size_allocate (widget=widget@entry=0x1996240, allocation=allocation@entry=0x7fffffffc690)
    at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwidget.c:6151
No locals.
#23 0x00007ffff6d78811 in gtk_window_move_resize (window=0x1996240) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwindow.c:9147
        allocation = {
          x = 0, 
          y = 0, 
          width = 443, 
          height = 627
        }
        new_flags = 106
        current_width = 443
        priv = 0x1996010
        widget = 0x1996240
        info = 0x1b2a910
        new_geometry = {
          min_width = 452, 
          min_height = 156, 
          max_width = 0, 
          max_height = 0, 
          base_width = 38, 
          base_height = 87, 
          width_inc = 9, 
          height_inc = 18, 
          min_aspect = 0, 
          max_aspect = 0, 
          win_gravity = GDK_GRAVITY_NORTH_WEST
        }
        new_request = {
          x = 0, 
          y = 0, 
          width = 452, 
          height = 627
        }
        configure_request_pos_changed = 0
        hints_changed = <optimized out>
        current_height = <optimized out>
        container = 0x1996240
        gdk_window = 0x1707240
---Type <return> to continue, or q <return> to quit---
        configure_request_size_changed = 0
        saved_last_info = {
          geometry = {
            min_width = 452, 
            min_height = 156, 
            max_width = 0, 
            max_height = 0, 
            base_width = 38, 
            base_height = 87, 
            width_inc = 9, 
            height_inc = 18, 
            min_aspect = <optimized out>, 
            max_aspect = <optimized out>, 
            win_gravity = <optimized out>
          }, 
          flags = <optimized out>, 
          configure_request = {
            x = <optimized out>, 
            y = <optimized out>, 
            width = <optimized out>, 
            height = <optimized out>
          }
        }
#24 gtk_window_check_resize (container=0x1996240) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkwindow.c:7916
No locals.
#25 0x00007ffff540a474 in _g_closure_invoke_va (closure=0x7ffff6db7edf, closure@entry=0x167b5c0, return_value=0x8, return_value@entry=0x0, instance=0x7ffff5185e25, 
    instance@entry=0x1996240, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args@entry=0x7fffffffc900, n_params=-153018873, param_types=0x1682470)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:831
        marshal = 0x0
        marshal_data = 0x7ffff6e11e07
        __FUNCTION__ = "_g_closure_invoke_va"
#26 0x00007ffff5424087 in g_signal_emit_valist (instance=0x1996240, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffc900)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3218
        return_accu = <optimized out>
        accu = {
          g_type = 0, 
          data = {{
              v_int = 0, 
              v_uint = 0, 
              v_long = 0, 
              v_ulong = 0, 
              v_int64 = 0, 
              v_uint64 = 0, 
              v_float = 0, 
              v_double = 0, 
              v_pointer = 0x0
            }, {
              v_int = 0, 
              v_uint = 0, 
---Type <return> to continue, or q <return> to quit---
              v_long = 0, 
              v_ulong = 0, 
              v_int64 = 0, 
              v_uint64 = 0, 
              v_float = 0, 
              v_double = 0, 
              v_pointer = 0x0
            }}
        }
        accumulator = 0x0
        emission = {
          next = 0x7fffffffcb20, 
          instance = 0x1996240, 
          ihint = {
            signal_id = 74, 
            detail = 0, 
            run_type = G_SIGNAL_RUN_LAST
          }, 
          state = EMISSION_RUN, 
          chain_type = 23647328
        }
        signal_id = 74
        instance_type = <optimized out>
        emission_return = {
          g_type = 0, 
          data = {{
              v_int = 0, 
              v_uint = 0, 
              v_long = 0, 
              v_ulong = 0, 
              v_int64 = 0, 
              v_uint64 = 0, 
              v_float = 0, 
              v_double = 0, 
              v_pointer = 0x0
            }, {
              v_int = 0, 
              v_uint = 0, 
              v_long = 0, 
              v_ulong = 0, 
              v_int64 = 0, 
              v_uint64 = 0, 
              v_float = 0, 
              v_double = 0, 
              v_pointer = 0x0
            }}
        }
        rtype = 4
        static_scope = 0
---Type <return> to continue, or q <return> to quit---
        fastpath_handler = <optimized out>
        closure = 0x167b5c0
        run_type = <optimized out>
        l = <optimized out>
        fastpath = <optimized out>
        instance_and_params = <optimized out>
        signal_return_type = <optimized out>
        param_values = <optimized out>
        i = <optimized out>
        n_params = <optimized out>
        __FUNCTION__ = "g_signal_emit_valist"
#27 0x00007ffff54249df in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3365
        var_args = {{
            gp_offset = 24, 
            fp_offset = 48, 
            overflow_arg_area = 0x7fffffffc9e0, 
            reg_save_area = 0x7fffffffc920
          }}
#28 0x00007ffff6b821fc in gtk_container_idle_sizer (clock=0x170b250, container=0x1996240) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkcontainer.c:1755
No locals.
#29 0x00007ffff540a474 in _g_closure_invoke_va (closure=0x7ffff6db7edf, closure@entry=0x1e53780, return_value=0x8, return_value@entry=0x0, instance=0x7ffff5185e25, 
    instance@entry=0x170b250, args=0x7ffff6e121c0 <__FUNCTION__.35024>, args@entry=0x7fffffffcc48, n_params=-153018873, param_types=0x1682470)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:831
        marshal = 0x0
        marshal_data = 0x7ffff6e11e07
        __FUNCTION__ = "_g_closure_invoke_va"
#30 0x00007ffff5424087 in g_signal_emit_valist (instance=0x170b250, signal_id=<optimized out>, detail=0, var_args=0x7fffffffcc48)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3218
        return_accu = <optimized out>
        accu = {
          g_type = 0, 
          data = {{
              v_int = 0, 
              v_uint = 0, 
              v_long = 0, 
              v_ulong = 0, 
              v_int64 = 0, 
              v_uint64 = 0, 
              v_float = 0, 
              v_double = 0, 
              v_pointer = 0x0
            }, {
              v_int = 0, 
              v_uint = 0, 
              v_long = 0, 
              v_ulong = 0, 
              v_int64 = 0, 
              v_uint64 = 0, 
---Type <return> to continue, or q <return> to quit---
              v_float = 0, 
              v_double = 0, 
              v_pointer = 0x0
            }}
        }
        accumulator = 0x0
        emission = {
          next = 0x0, 
          instance = 0x170b250, 
          ihint = {
            signal_id = 140, 
            detail = 0, 
            run_type = G_SIGNAL_RUN_FIRST
          }, 
          state = EMISSION_RUN, 
          chain_type = 24157520
        }
        signal_id = 140
        instance_type = <optimized out>
        emission_return = {
          g_type = 0, 
          data = {{
              v_int = 0, 
              v_uint = 0, 
              v_long = 0, 
              v_ulong = 0, 
              v_int64 = 0, 
              v_uint64 = 0, 
              v_float = 0, 
              v_double = 0, 
              v_pointer = 0x0
            }, {
              v_int = 0, 
              v_uint = 0, 
              v_long = 0, 
              v_ulong = 0, 
              v_int64 = 0, 
              v_uint64 = 0, 
              v_float = 0, 
              v_double = 0, 
              v_pointer = 0x0
            }}
        }
        rtype = 4
        static_scope = 0
        fastpath_handler = <optimized out>
        closure = 0x1e53780
        run_type = <optimized out>
        l = <optimized out>
---Type <return> to continue, or q <return> to quit---
        fastpath = <optimized out>
        instance_and_params = <optimized out>
        signal_return_type = <optimized out>
        param_values = <optimized out>
        i = <optimized out>
        n_params = <optimized out>
        __FUNCTION__ = "g_signal_emit_valist"
#31 0x00007ffff5424f2a in g_signal_emit_by_name (instance=0x7ffff6db7edf, instance@entry=0x170b250, detailed_signal=0x8 <error: Cannot access memory at address 0x8>, 
    detailed_signal@entry=0x7ffff681b736 "layout") at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3405
        var_args = {{
            gp_offset = 16, 
            fp_offset = 48, 
            overflow_arg_area = 0x7fffffffcd80, 
            reg_save_area = 0x7fffffffcc90
          }}
        detail = 0
        signal_id = 140
        __FUNCTION__ = "g_signal_emit_by_name"
#32 0x00007ffff67b5974 in gdk_frame_clock_paint_idle (data=0x170b250) at /tmp/buildd/gtk+3.0-3.14.5/./gdk/gdkframeclockidle.c:408
        iter = 1
        clock = 0x170b250
        clock_idle = 0x170b250
        priv = 0x170b170
        skip_to_resume_events = 0
        timings = 0x1d9dcc0
#33 0x00007ffff67a7e78 in gdk_threads_dispatch (data=0x1860b40, data@entry=<error reading variable: value has been optimized out>)
    at /tmp/buildd/gtk+3.0-3.14.5/./gdk/gdk.c:654
        dispatch = 0x1860b40
        ret = 0
#34 0x00007ffff5135613 in g_timeout_dispatch (source=0x1e58820, callback=<optimized out>, user_data=<optimized out>) at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:4520
        timeout_source = 0x1e58820
        again = <optimized out>
#35 0x00007ffff5134b6d in g_main_dispatch (context=0x16eacf0) at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3111
        dispatch = 0x7ffff5135600 <g_timeout_dispatch>
        prev_source = 0x0
        was_in_call = 0
        user_data = 0x1860b40
        callback = 0x7ffff67a7e50 <gdk_threads_dispatch>
        cb_funcs = <optimized out>
        cb_data = 0x1c8fec0
        need_destroy = <optimized out>
        source = 0x1e58820
        current = 0x170f5c0
        i = 0
#36 g_main_context_dispatch (context=context@entry=0x16eacf0) at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3710
No locals.
#37 0x00007ffff5134f48 in g_main_context_iterate (context=context@entry=0x16eacf0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3781
        max_priority = 120
---Type <return> to continue, or q <return> to quit---
        timeout = 0
        some_ready = 1
        nfds = <optimized out>
        allocated_nfds = 3
        fds = 0x17f6c30
#38 0x00007ffff5134ffc in g_main_context_iteration (context=0x16eacf0, context@entry=0x0, may_block=may_block@entry=1) at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3842
        retval = <optimized out>
#39 0x00007ffff6c2dcc5 in gtk_main_iteration () at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkmain.c:1308
No locals.
#40 0x0000000000545c63 in XTread_socket (terminal=0x12fdb80, hold_quit=0x7fffffffcf60) at xterm.c:8775
        count = 0
        event_found = false
        dpyinfo = 0x1912800
#41 0x0000000000592262 in gobble_input () at keyboard.c:6771
        nr = 0
        hold_quit = {
          kind = NO_EVENT, 
          part = scroll_bar_nowhere, 
          code = 0, 
          modifiers = 0, 
          x = 0, 
          y = 0, 
          timestamp = 0, 
          frame_or_window = 0, 
          arg = 0
        }
        next = 0x0
        nread = 0
        err = false
        t = 0x12fdb80
#42 0x00000000005927e7 in handle_async_input () at keyboard.c:7023
        nread = 0
#43 0x0000000000592806 in process_pending_signals () at keyboard.c:7037
No locals.
#44 0x0000000000604c49 in Fmake_list (length=0, init=0) at alloc.c:2705
        val = 31958179
        size = 0
#45 0x00000000006361fb in concat (nargs=1, args=0x7fffffffd1a8, target_type=Lisp_Cons, last_special=false) at fns.c:633
        val = 0
        tail = 0
        this = 22459043
        toindex = 0
        toindex_byte = 0
        result_len = 1
        result_len_byte = 1
        argnum = 1
        last_tail = 0
        prev = 0
        some_multibyte = false
---Type <return> to continue, or q <return> to quit---
        textprops = 0x0
        num_textprops = 0
        sa_avail = 16384
        sa_count = 3
        sa_must_free = false
#46 0x0000000000635b9a in Fcopy_sequence (arg=22459043) at fns.c:501
No locals.
#47 0x000000000058c928 in timer_check () at keyboard.c:4447
        nexttime = {
          tv_sec = 0, 
          tv_nsec = 0
        }
        timers = 0
        idle_timers = 0
        tem = 0
#48 0x000000000058a0f6 in readable_events (flags=1) at keyboard.c:3304
No locals.
#49 0x00000000005920ac in get_input_pending (flags=1) at keyboard.c:6686
No locals.
#50 0x0000000000599894 in detect_input_pending_run_timers (do_display=true) at keyboard.c:9817
        old_timers_run = 6
#51 0x000000000068a0db in wait_reading_process_output (time_limit=0, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=0, wait_proc=0x0, just_wait_proc=0)
    at process.c:4963
        old_timers_run = 6
        old_buffer = 0xde1100
        old_window = 20934853
        leave = false
        process_skipped = false
        channel = 0
        nfds = 1
        Available = {
          fds_bits = {512, 0 <repeats 15 times>}
        }
        Writeok = {
          fds_bits = {0 <repeats 16 times>}
        }
        check_write = true
        check_delay = 0
        no_avail = false
        xerrno = 11
        proc = 140737488344704
        timeout = {
          tv_sec = 0, 
          tv_nsec = 0
        }
        end_time = {
          tv_sec = 51926, 
          tv_nsec = 526406277
        }
---Type <return> to continue, or q <return> to quit---
        timer_delay = {
          tv_sec = 0, 
          tv_nsec = 242146435
        }
        got_output_end_time = {
          tv_sec = 1448483268, 
          tv_nsec = 894015374
        }
        wait = INFINITY
        got_some_output = -1
        count = 2
        now = {
          tv_sec = 0, 
          tv_nsec = -1
        }
#52 0x000000000058b16c in kbd_buffer_get_event (kbp=0x7fffffffd818, used_mouse_menu=0x7fffffffddff, end_time=0x0) at keyboard.c:3795
        do_display = true
        obj = 893985407
#53 0x0000000000586701 in read_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffffdbc0, used_mouse_menu=0x7fffffffddff) at keyboard.c:2121
        c = 0
        save_jump = {{
            __jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, 
            __mask_was_saved = 0, 
            __saved_mask = {
              __val = {0 <repeats 16 times>}
            }
          }}
        kb = 0x0
#54 0x00000000005869d0 in read_decoded_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffffdbc0, prev_event=0, used_mouse_menu=0x7fffffffddff)
    at keyboard.c:2184
        nextevt = 14249584
        frame = 0x7fffffffda70
        terminal = 0x0
        events = {140737488345584, 14249584, 0, 0, 140737488345584, 5742676, 0, 31935987, 140737488345648, 5808618, 935, 4294967296, 0, 5742676, 20934848, 0}
        n = 0
#55 0x000000000058863c in read_char (commandflag=1, map=30806627, prev_event=0, used_mouse_menu=0x7fffffffddff, end_time=0x0) at keyboard.c:2779
        c = 0
        jmpcount = 2
        local_getcjmp = {{
            __jmpbuf = {0, -308247075226988984, 21848269, 44304, 0, 0, -308247075057119672, 308247691226828360}, 
            __mask_was_saved = 0, 
            __saved_mask = {
              __val = {14249584, 140737488346176, 0, 140737488346176, 5742676, 18912080, 14249584, 140737488346320, 0, 140737488346224, 5742676, 0, 19261859, 
                140737488346320, 6497538, 0}
            }
          }}
        save_jump = {{
            __jmpbuf = {0, 0, 0, 25769803776, 14553344, 140737488345928, 5749423, 25769803776}, 
            __mask_was_saved = 14553349, 
---Type <return> to continue, or q <return> to quit---
            __saved_mask = {
              __val = {140737488345960, 14553344, 140737488345952, 5749640, 25784357125, 14553344, 140737488346008, 5749423, 25769833104, 14553349, 6966294, 14553344, 
                140737488346032, 5749640, 14553349, 140737488346064}
            }
          }}
        tem = 535296
        save = 0
        previous_echo_area_message = 0
        also_record = 0
        reread = false
        recorded = false
        polling_stopped_here = true
        orig_kboard = 0x171ac90
#56 0x0000000000597c93 in read_key_sequence (keybuf=0x7fffffffdfb0, bufsize=30, prompt=0, dont_downcase_last=false, can_return_switch_frame=true, 
    fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9018
        interrupted_kboard = 0x171ac90
        interrupted_frame = 0x13f60b0
        key = 25774401020
        used_mouse_menu = false
        echo_local_start = 0
        last_real_key_start = 0
        keys_local_start = 0
        new_binding = 5749423
        count = 2
        t = 0
        echo_start = 0
        keys_start = 0
        current_binding = 30806627
        first_event = 0
        first_unbound = 31
        mock_input = 0
        fkey = {
          parent = 18643683, 
          map = 18643683, 
          start = 0, 
          end = 0
        }
        keytran = {
          parent = 14507587, 
          map = 14507587, 
          start = 0, 
          end = 0
        }
        indec = {
          parent = 18644019, 
          map = 18644019, 
          start = 0, 
          end = 0
        }
---Type <return> to continue, or q <return> to quit---
        shift_translated = false
        delayed_switch_frame = 0
        original_uppercase = 5749423
        original_uppercase_position = -1
        dummyflag = false
        starting_buffer = 0xde1100
        fake_prefixed_keys = 0
#57 0x00000000005846af in command_loop_1 () at keyboard.c:1343
        cmd = 18912
        keybuf = {7068, 28272, 140737488347120, 6356275, 14086960, 0, 5749288, 0, 140737488347216, 6359201, 0, 28272, 0, 14249584, 14086960, 0, 140737488347216, 
          5742676, 140737488347248, 0, 140737488347312, 6497538, 14700803, 14249584, 140737488347312, 0, 140737488347296, 5742676, 14277856, 0}
        i = 0
        prev_modiff = 0
        prev_buffer = 0x0
        already_adjusted = false
#58 0x000000000062d0e3 in internal_condition_case (bfun=0x58426d <command_loop_1>, handlers=18912, hfun=0x5838db <cmd_error>) at eval.c:1309
        val = 14700803
        c = 0x165cc10
#59 0x0000000000583e9b in command_loop_2 (ignore=0) at keyboard.c:1086
        val = 0
#60 0x000000000062c68d in internal_catch (tag=45696, func=0x583e72 <command_loop_2>, arg=0) at eval.c:1074
        val = 0
        c = 0x165cae0
#61 0x0000000000583e3b in command_loop () at keyboard.c:1065
No locals.
#62 0x00000000005833ba in recursive_edit_1 () at keyboard.c:671
        count = 1
        val = 140737488347696
#63 0x00000000005835c5 in Frecursive_edit () at keyboard.c:742
        count = 0
        buffer = 0
#64 0x00000000005813d8 in main (argc=2, argv=0x7fffffffe438) at emacs.c:1656
        dummy = 140737488347872
        stack_bottom_variable = 0 '\000'
        do_initial_setlocale = true
        dumping = false
        skip_args = 0
        rlim = {
          rlim_cur = 8720000, 
          rlim_max = 18446744073709551615
        }
        no_loadup = false
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x0
        original_pwd = 0x0

bug#22000: 25.0.50; Running dired changes frame width, gtk_distribute_natural_allocation throws assertion

[martin rudalics]

 > 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

bug#22000: 25.0.50; Running dired changes frame width, gtk_distribute_natural_allocation throws assertion

[David Engster]

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

bug#22000: 25.0.50; Running dired changes frame width, gtk_distribute_natural_allocation throws assertion

[martin rudalics]

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

bug#22000: 25.0.50; Running dired changes frame width, gtk_distribute_natural_allocation throws assertion

[David Engster]

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

bug#22000: 25.0.50; Running dired changes frame width, gtk_distribute_natural_allocation throws assertion

[martin rudalics]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 356 bytes --]

Tags: patch

This patch attempts to address the menu-bar interaction with the
frame size: I've been using it locally for a short while now.

It does make the menu bar taller than it was - This may be
addressable by using overlay scrollbars but there is currently
a bad focus interaction with those so the patch suppresses them
(overlay scrollbars) for now.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: TEXT/x-diff; name=0001-GTK3-menu-bars-force-frame-resizing-Bug-22000.patch, Size: 3911 bytes --]

From c00e61e01fb2c15516ab753897d6bd327845c1ae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vivek=20Das=C2=A0Mohapatra?= <vivek@collabora.com>
Date: Sun, 15 Jul 2018 18:59:59 +0100
Subject: [PATCH] GTK3 menu bars force frame resizing (Bug#22000)

Menu bars force the frame they are in to resize when the menu bar
width exceeds the frame width, both at the point the menu bar grows
past the frame width and whenever the gtk idle resize callback is
triggered.

The effect is that the user's frame width is effectively ignored, and
emacs will semi-predictably resize itself to accommodate the menu bar.

This effect can be suppressed by wrapping the menu bar in a scrollable
window.
---
 src/gtkutil.c | 31 ++++++++++++++++++++++++++-----
 src/xterm.h   |  1 +
 2 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/src/gtkutil.c b/src/gtkutil.c
index 69325ff00a..d954eca401 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -3461,6 +3461,7 @@ xg_update_frame_menubar (struct frame *f)
 {
   struct x_output *x = f->output_data.x;
   GtkRequisition req;
+  GtkScrolledWindow *sw;
 
   if (!x->menubar_widget || gtk_widget_get_mapped (x->menubar_widget))
     return;
@@ -3470,12 +3471,30 @@ xg_update_frame_menubar (struct frame *f)
 
   block_input ();
 
-  gtk_box_pack_start (GTK_BOX (x->vbox_widget), x->menubar_widget,
-                      FALSE, FALSE, 0);
-  gtk_box_reorder_child (GTK_BOX (x->vbox_widget), x->menubar_widget, 0);
+  /* Put the menu bar inside a scrolled window so that adding items
+     to the menu bar (such as when entering dired mode or activating
+     a minor more) does not trigger a frame resize:*/
+  x->menubar_viewport = gtk_scrolled_window_new(NULL, NULL);
+  sw = GTK_SCROLLED_WINDOW (x->menubar_viewport);
+
+  /* Leave the keyboard focus where it is when clicking the scrollwindow: */
+  gtk_widget_set_focus_on_click (GTK_WIDGET(sw), FALSE);
+
+  gtk_scrolled_window_set_policy (sw, GTK_POLICY_AUTOMATIC, GTK_POLICY_NEVER);
+
+  /* If we don't set this then the scrollable keeps focus when the user
+     interacts with the scrollbar, at least until the menubar is clicked.
+     Overlay scrolling is more compact but until the focus problem is fixed
+     it's not livable with. */
+  gtk_scrolled_window_set_overlay_scrolling (sw, FALSE);
+
+  gtk_container_add (GTK_CONTAINER (sw), x->menubar_widget);
+
+  gtk_box_pack_start (GTK_BOX (x->vbox_widget), GTK_WIDGET(sw), FALSE, FALSE, 0);
+  gtk_box_reorder_child (GTK_BOX (x->vbox_widget), GTK_WIDGET(sw), 0);
 
   g_signal_connect (x->menubar_widget, "map", G_CALLBACK (menubar_map_cb), f);
-  gtk_widget_show_all (x->menubar_widget);
+  gtk_widget_show_all (x->menubar_viewport);
   gtk_widget_get_preferred_size (x->menubar_widget, NULL, &req);
 
   if (FRAME_MENUBAR_HEIGHT (f) != req.height)
@@ -3498,9 +3517,11 @@ free_frame_menubar (struct frame *f)
     {
       block_input ();
 
-      gtk_container_remove (GTK_CONTAINER (x->vbox_widget), x->menubar_widget);
+      gtk_container_remove (GTK_CONTAINER (x->menubar_viewport), x->menubar_widget);
+      gtk_container_remove (GTK_CONTAINER (x->vbox_widget), x->menubar_viewport);
        /* The menubar and its children shall be deleted when removed from
           the container.  */
+      x->menubar_viewport = 0;
       x->menubar_widget = 0;
       FRAME_MENUBAR_HEIGHT (f) = 0;
       adjust_frame_size (f, -1, -1, 2, 0, Qmenu_bar_lines);
diff --git a/src/xterm.h b/src/xterm.h
index 1849a5c953..9bf3d9778b 100644
--- a/src/xterm.h
+++ b/src/xterm.h
@@ -583,6 +583,7 @@ struct x_output
   /* The widget used for laying out widgets horizontally.  */
   GtkWidget *hbox_widget;
   /* The menubar in this frame.  */
+  GtkWidget *menubar_viewport;
   GtkWidget *menubar_widget;
   /* The tool bar in this frame  */
   GtkWidget *toolbar_widget;
-- 
2.11.0

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

 > 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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

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.

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 662 bytes --]

I have #ifdef'd the calls you mentioned with GTK_CHECK_VERSION guards.

I also checked with one of the gnome/gtk devs and wrapping a
widget with strict ideas about its size is how you are supposed
to prevent its size from propagating: I suppose an alternative
would be some widget that doesn't resize or scroll at all,
but the basic approach would be the same.

I could not find a way to make overlay scrolbars behave, I think it's 
probably a bug in overlay scrollbars since classic scrollbars behave
just fine: I don't think that will be a problem as 3.16 is when overlay 
scrolling was introduced and that was also when the disabling function
was provided.



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: TEXT/x-diff; name=0001-GTK3-menu-bars-force-frame-resizing-Bug-22000.patch, Size: 3999 bytes --]

From cd3e84356de102eab24e57042285c28ac2b2c970 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vivek=20Das=C2=A0Mohapatra?= <vivek@collabora.com>
Date: Sun, 15 Jul 2018 18:59:59 +0100
Subject: [PATCH] GTK3 menu bars force frame resizing (Bug#22000)

Menu bars force the frame they are in to resize when the menu bar
width exceeds the frame width, both at the point the menu bar grows
past the frame width and whenever the gtk idle resize callback is
triggered.

The effect is that the user's frame width is effectively ignored, and
emacs will semi-predictably resize itself to accommodate the menu bar.

This effect can be suppressed by wrapping the menu bar in a scrollable
window.
---
 src/gtkutil.c | 34 +++++++++++++++++++++++++++++-----
 src/xterm.h   |  1 +
 2 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/src/gtkutil.c b/src/gtkutil.c
index 69325ff00a..d16274f6ab 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -3461,6 +3461,7 @@ xg_update_frame_menubar (struct frame *f)
 {
   struct x_output *x = f->output_data.x;
   GtkRequisition req;
+  GtkScrolledWindow *sw;
 
   if (!x->menubar_widget || gtk_widget_get_mapped (x->menubar_widget))
     return;
@@ -3470,12 +3471,33 @@ xg_update_frame_menubar (struct frame *f)
 
   block_input ();
 
-  gtk_box_pack_start (GTK_BOX (x->vbox_widget), x->menubar_widget,
-                      FALSE, FALSE, 0);
-  gtk_box_reorder_child (GTK_BOX (x->vbox_widget), x->menubar_widget, 0);
+  /* Put the menu bar inside a scrolled window so that adding items
+     to the menu bar (such as when entering dired mode or activating
+     a minor more) does not trigger a frame resize:*/
+  x->menubar_viewport = gtk_scrolled_window_new(NULL, NULL);
+  sw = GTK_SCROLLED_WINDOW (x->menubar_viewport);
+  gtk_scrolled_window_set_policy (sw, GTK_POLICY_AUTOMATIC, GTK_POLICY_NEVER);
+
+  /* Leave the keyboard focus where it is when clicking the scrollwindow: */
+#if GTK_CHECK_VERSION (3, 20, 0)
+  gtk_widget_set_focus_on_click (GTK_WIDGET(sw), FALSE);
+#endif
+
+#if GTK_CHECK_VERSION (3, 16, 0)
+  /* If we don't set this then the scrollable keeps focus when the user
+     interacts with the scrollbar, at least until the menubar is clicked.
+     Overlay scrolling is more compact but until the focus problem is fixed
+     it's not livable with. */
+  gtk_scrolled_window_set_overlay_scrolling (sw, FALSE);
+#endif
+
+  gtk_container_add (GTK_CONTAINER (sw), x->menubar_widget);
+
+  gtk_box_pack_start (GTK_BOX (x->vbox_widget), GTK_WIDGET(sw), FALSE, FALSE, 0);
+  gtk_box_reorder_child (GTK_BOX (x->vbox_widget), GTK_WIDGET(sw), 0);
 
   g_signal_connect (x->menubar_widget, "map", G_CALLBACK (menubar_map_cb), f);
-  gtk_widget_show_all (x->menubar_widget);
+  gtk_widget_show_all (x->menubar_viewport);
   gtk_widget_get_preferred_size (x->menubar_widget, NULL, &req);
 
   if (FRAME_MENUBAR_HEIGHT (f) != req.height)
@@ -3498,9 +3520,11 @@ free_frame_menubar (struct frame *f)
     {
       block_input ();
 
-      gtk_container_remove (GTK_CONTAINER (x->vbox_widget), x->menubar_widget);
+      gtk_container_remove (GTK_CONTAINER (x->menubar_viewport), x->menubar_widget);
+      gtk_container_remove (GTK_CONTAINER (x->vbox_widget), x->menubar_viewport);
        /* The menubar and its children shall be deleted when removed from
           the container.  */
+      x->menubar_viewport = 0;
       x->menubar_widget = 0;
       FRAME_MENUBAR_HEIGHT (f) = 0;
       adjust_frame_size (f, -1, -1, 2, 0, Qmenu_bar_lines);
diff --git a/src/xterm.h b/src/xterm.h
index 1849a5c953..9bf3d9778b 100644
--- a/src/xterm.h
+++ b/src/xterm.h
@@ -583,6 +583,7 @@ struct x_output
   /* The widget used for laying out widgets horizontally.  */
   GtkWidget *hbox_widget;
   /* The menubar in this frame.  */
+  GtkWidget *menubar_viewport;
   GtkWidget *menubar_widget;
   /* The tool bar in this frame  */
   GtkWidget *toolbar_widget;
-- 
2.11.0

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

 > 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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 255 bytes --]

>> The height of the initial window goes down from 35 lines (630 pixels)
>> to 33 lines (595 pixels).

This patch (added on top of the previous one) should fix the frame 
size calculation.

Still looking into whether there's a purely truncating solution.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: TEXT/x-diff; name=0002-GTK3-correct-frame-height-calculation-with-scrollabl.patch, Size: 1483 bytes --]

From eaae86389d2862dc10804f45161f07cb475b49a0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vivek=20Das=C2=A0Mohapatra?= <vivek@collabora.com>
Date: Tue, 17 Jul 2018 19:53:42 +0100
Subject: [PATCH 2/2] GTK3 - correct frame height calculation with scrollable
 menu bars

The frame height calculation needs to be done based on the new
scrollable window that wraps the menu bars to be accurate.
---
 src/gtkutil.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/gtkutil.c b/src/gtkutil.c
index d16274f6ab..dc78976d22 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -3445,7 +3445,11 @@ menubar_map_cb (GtkWidget *w, gpointer user_data)
 {
   GtkRequisition req;
   struct frame *f = user_data;
-  gtk_widget_get_preferred_size (w, NULL, &req);
+  struct x_output *x = f->output_data.x;
+
+  /* Use the menubar viewport for size if there is one: */
+  gtk_widget_get_preferred_size (x->menubar_viewport ?: w, NULL, &req);
+
   if (FRAME_MENUBAR_HEIGHT (f) != req.height)
     {
       FRAME_MENUBAR_HEIGHT (f) = req.height;
@@ -3498,7 +3502,7 @@ xg_update_frame_menubar (struct frame *f)
 
   g_signal_connect (x->menubar_widget, "map", G_CALLBACK (menubar_map_cb), f);
   gtk_widget_show_all (x->menubar_viewport);
-  gtk_widget_get_preferred_size (x->menubar_widget, NULL, &req);
+  gtk_widget_get_preferred_size (x->menubar_viewport, NULL, &req);
 
   if (FRAME_MENUBAR_HEIGHT (f) != req.height)
     {
-- 
2.11.0

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

 > 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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

 > 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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2259 bytes --]

> Can you point me to where gtk does that?

Backtrace (attached):

   gdk_frame_clock_paint_idle
   …
   → gtk_container_idle_sizer
   …
   → gtk_distribute_natural_allocation

Is the path, I think.

> I suppose the container respecting its wishes is that of the Emacs
> frame's window.  And if that container were a scrolled window, it
> would not auto-resize.  Do I reason correctly?

Initially it's the box (vbox?) that the menubar is added to.
Not sure that's the top level widget.

> I'm probably too silly to understand the semantics of containers: The
> menu bar widget's size is not fixed so its RTL behavior (and the
> font/translation issues gtkfixed talks about) would not be affected.

I'm not overly familiar with GTK myself - I'm just going by the docs
for gtk fixed. You may be correct: I'm not going to speculate further
or try to understand the underlying code, I'm just going to try it :)

> Only the "virtual" container we'd add would have fixed size but this
> does not mean that it passes on the fixed size property to the menu
> bar's widget.  Inherently, this means that we would be cheating GTK
> another time.  Or am I wrong?

IIUC you are right - that's how you're supposed to do it - I just don't
know if there's a non-deprecated widget that does what we want.

Worst case scenario: If I grab the scrolled window class and mutilate it
till it does what we want, would you consider emacs carrying that widget
class in its code? It shouldn't change any of the build dependencies.

NOTE: FWIW even the hbox and vbox we are using are deprecated and have
been for a while, so this whole area of code is going to need to be 
converted over to gtk grid at some point anyway.

>> You can turn scrollbars off in a scrolled window but unfortunately
>
> This is incoherent, at least.  Could we suppress horizontal scroll
> bars separately in a scrolled window (because I think that these are
> responsible for the height increase of the menu bar)?

You can suppress the scrollbars independently, but that's what restores
the unwanted resizing behaviour in that direction: Suppress the vertical
scrollbar and suddenly vertical size requests are honoured, suppress
the horizontal and suddenly the menu bar can force the frame size again.

[-- Attachment #2: Type: TEXT/plain, Size: 64184 bytes --]

#0  0x00007f6478ab875b in raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
        resultvar = 0
        pid = <optimized out>
#1  0x00000000004f0184 in terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40) at emacs.c:381
No locals.
#2  0x0000000000508fd3 in emacs_abort () at sysdep.c:2247
No locals.
#3  0x000000000056463b in Fsignal (error_symbol=error_symbol@entry=28656, data=86599795) at eval.c:1478
        conditions = <optimized out>
        string = <optimized out>
        real_error_symbol = 28656
        clause = <optimized out>
        h = <optimized out>
#4  0x0000000000564649 in xsignal (error_symbol=error_symbol@entry=28656, data=<optimized out>) at eval.c:1577
No locals.
#5  0x0000000000565157 in xsignal1 (error_symbol=error_symbol@entry=28656, arg=<optimized out>) at eval.c:1592
No locals.
#6  0x0000000000533fee in compile_pattern_1 (posix=<optimized out>, translate=0, pattern=<optimized out>, cp=0xb935d0 <searchbufs+6480>) at search.c:154
        val = 0x600576 "Regular expression too big"
        old = 0
#7  compile_pattern (pattern=pattern@entry=61362260, regp=regp@entry=0x0, translate=translate@entry=0, posix=posix@entry=false, multibyte=<optimized out>) at search.c:237
        cp = 0xb935d0 <searchbufs+6480>
        cpp = <optimized out>
#8  0x000000000053619d in fast_string_match_internal (regexp=regexp@entry=61362260, string=string@entry=61914372, table=table@entry=0) at search.c:471
        val = 0
        bufp = <optimized out>
#9  0x000000000051dd61 in fast_string_match (string=61914372, regexp=61362260) at lisp.h:4010
No locals.
#10 Ffind_file_name_handler (filename=filename@entry=61914372, operation=operation@entry=19872) at fileio.c:292
        operations = 0
        chain = 61546355
        inhibited_handlers = 0
        result = 0
        pos = -1
#11 0x000000000051f3c0 in Fexpand_file_name (name=61914372, default_directory=default_directory@entry=0) at fileio.c:809
        nm = <optimized out>
        nmlim = <optimized out>
        newdir = <optimized out>
        newdirlim = <optimized out>
        target = <optimized out>
        tlen = <optimized out>
        pw = <optimized out>
        length = <optimized out>
        nbytes = <optimized out>
        handler = <optimized out>
        result = <optimized out>
        handled_name = <optimized out>
        multibyte = <optimized out>
        hdir = <optimized out>
        sa_avail = 16384
        sa_must_free = false
#12 0x0000000000524298 in Fdo_auto_save (no_message=<optimized out>, no_message@entry=44448, current_only=current_only@entry=0) at fileio.c:5521
        listfile = <optimized out>
        old = 0x37e8330
        tail = <optimized out>
        auto_saved = false
        do_handled_files = <optimized out>
        oquit = 0
        stream = 0x0
        orig_minibuffer_auto_raise = false
        old_message_p = false
        auto_save_unwind = {stream = 0x7f647864bf6e, auto_raise = 40}
#13 0x00000000004effa0 in shut_down_emacs (sig=sig@entry=11, stuff=stuff@entry=0) at emacs.c:2000
No locals.
#14 0x00000000004f0155 in terminate_due_to_signal (sig=sig@entry=11, backtrace_limit=backtrace_limit@entry=40) at emacs.c:365
No locals.
#15 0x0000000000507c7e in handle_fatal_signal (sig=sig@entry=11) at sysdep.c:1601
No locals.
#16 0x0000000000507e33 in deliver_thread_signal (sig=sig@entry=11, handler=0x507c70 <handle_fatal_signal>) at sysdep.c:1575
No locals.
#17 0x0000000000507ebc in deliver_fatal_thread_signal (sig=11) at sysdep.c:1613
No locals.
#18 handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>) at sysdep.c:1695
        fatal = <optimized out>
#19 <signal handler called>
No locals.
#20 mark_object (arg=<optimized out>) at alloc.c:6446
        ptr = 0x5ea9170
        obj = <optimized out>
        po = <optimized out>
        cdr_count = <optimized out>
#21 0x000000000054bb63 in mark_object (arg=<optimized out>) at alloc.c:6539
        obj = <optimized out>
        po = <optimized out>
        cdr_count = 2174
#22 0x000000000054d28e in mark_maybe_pointer (p=0x52eb480) at alloc.c:4845
        obj = <optimized out>
        m = <optimized out>
#23 mark_memory (end=0x7fff02b540a8, start=<optimized out>) at alloc.c:4894
        pp = 0x7fff02b514e8 "\200\264.\005"
#24 mark_stack (end=0x7fff02b4f898) at alloc.c:5038
No locals.
#25 garbage_collect_1 (end=0x7fff02b4f898) at alloc.c:5756
        nextb = <optimized out>
        i = <optimized out>
        retval = <optimized out>
        stack_top_variable = 0 '\000'
        message_p = false
        tot_before = 0
        total = {58591408, 0, 0, 8, 2, 5652410, 374496, 11808, 0, -6202091921070732288, 8}
#26 Fgarbage_collect () at alloc.c:5979
        end = 0x7fff02b4f898
#27 0x00000000005639cc in maybe_gc () at lisp.h:4656
No locals.
#28 Ffuncall (nargs=86946816, args=0x7fff02b4fa68) at eval.c:2643
        numargs = 1
        val = 333
        internal_args = 0x7fff02b4fa70
        count = 17
#29 0x00000000005988f3 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=args_template@entry=0, nargs=nargs@entry=0, 
    args=<optimized out>, args@entry=0x0) at bytecode.c:880
        targets = {0x598a78 <exec_byte_code+888>, 0x59a050 <exec_byte_code+6480>, 0x59a058 <exec_byte_code+6488>, 0x59a060 <exec_byte_code+6496>, 0x598838 <exec_byte_code+312>, 
          0x598840 <exec_byte_code+320>, 0x599be0 <exec_byte_code+5344>, 0x599c30 <exec_byte_code+5424>, 0x59a068 <exec_byte_code+6504>, 0x598b08 <exec_byte_code+1032>, 
          0x598ac0 <exec_byte_code+960>, 0x598b10 <exec_byte_code+1040>, 0x598a08 <exec_byte_code+776>, 0x598a10 <exec_byte_code+784>, 0x59a110 <exec_byte_code+6672>, 
          0x598ac8 <exec_byte_code+968>, 0x598b18 <exec_byte_code+1048>, 0x599ec0 <exec_byte_code+6080>, 0x59a320 <exec_byte_code+7200>, 0x599f08 <exec_byte_code+6152>, 
          0x598990 <exec_byte_code+656>, 0x598990 <exec_byte_code+656>, 0x59a2d8 <exec_byte_code+7128>, 0x599ec8 <exec_byte_code+6088>, 0x599f38 <exec_byte_code+6200>, 
          0x599f40 <exec_byte_code+6208>, 0x599f90 <exec_byte_code+6288>, 0x598b20 <exec_byte_code+1056>, 0x598880 <exec_byte_code+384>, 0x598880 <exec_byte_code+384>, 
          0x599ef0 <exec_byte_code+6128>, 0x599f10 <exec_byte_code+6160>, 0x599f88 <exec_byte_code+6280>, 0x599f98 <exec_byte_code+6296>, 0x599fa0 <exec_byte_code+6304>, 
          0x598b28 <exec_byte_code+1064>, 0x5988c8 <exec_byte_code+456>, 0x5988d0 <exec_byte_code+464>, 0x599f48 <exec_byte_code+6216>, 0x599f60 <exec_byte_code+6240>, 
          0x599fd8 <exec_byte_code+6360>, 0x599fd0 <exec_byte_code+6352>, 0x599fe0 <exec_byte_code+6368>, 0x598b30 <exec_byte_code+1072>, 0x598918 <exec_byte_code+536>, 
          0x598920 <exec_byte_code+544>, 0x598af0 <exec_byte_code+1008>, 0x599fa8 <exec_byte_code+6312>, 0x599ad0 <exec_byte_code+5072>, 0x5999f0 <exec_byte_code+4848>, 
          0x59a040 <exec_byte_code+6464>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 
          0x598a78 <exec_byte_code+888>, 0x5990b0 <exec_byte_code+2480>, 0x599140 <exec_byte_code+2624>, 0x599188 <exec_byte_code+2696>, 0x5991d0 <exec_byte_code+2768>, 
          0x599220 <exec_byte_code+2848>, 0x59a290 <exec_byte_code+7056>, 0x59a1d0 <exec_byte_code+6864>, 0x599268 <exec_byte_code+2920>, 0x59a250 <exec_byte_code+6992>, 
          0x59a210 <exec_byte_code+6928>, 0x5992a0 <exec_byte_code+2976>, 0x5992e0 <exec_byte_code+3040>, 0x599310 <exec_byte_code+3088>, 0x599350 <exec_byte_code+3152>, 
          0x599388 <exec_byte_code+3208>, 0x599410 <exec_byte_code+3344>, 0x599440 <exec_byte_code+3392>, 0x599480 <exec_byte_code+3456>, 0x5994c0 <exec_byte_code+3520>, 
          0x5994f0 <exec_byte_code+3568>, 0x599520 <exec_byte_code+3616>, 0x599560 <exec_byte_code+3680>, 0x5995a0 <exec_byte_code+3744>, 0x5995e0 <exec_byte_code+3808>, 
          0x599620 <exec_byte_code+3872>, 0x599658 <exec_byte_code+3928>, 0x599690 <exec_byte_code+3984>, 0x599718 <exec_byte_code+4120>, 0x599760 <exec_byte_code+4192>, 
          0x5997a8 <exec_byte_code+4264>, 0x599880 <exec_byte_code+4480>, 0x5997f8 <exec_byte_code+4344>, 0x599840 <exec_byte_code+4416>, 0x5998c0 <exec_byte_code+4544>, 
          0x599900 <exec_byte_code+4608>, 0x599938 <exec_byte_code+4664>, 0x599980 <exec_byte_code+4736>, 0x59a960 <exec_byte_code+8800>, 0x59a998 <exec_byte_code+8856>, 
          0x59a9d0 <exec_byte_code+8912>, 0x59a7c0 <exec_byte_code+8384>, 0x598960 <exec_byte_code+608>, 0x59a800 <exec_byte_code+8448>, 0x59a830 <exec_byte_code+8496>, 
          0x59a8b0 <exec_byte_code+8624>, 0x59a8f0 <exec_byte_code+8688>, 0x59a930 <exec_byte_code+8752>, 0x59a440 <exec_byte_code+7488>, 0x59a470 <exec_byte_code+7536>, 
          0x59a4a0 <exec_byte_code+7584>, 0x59a4d8 <exec_byte_code+7640>, 0x598a78 <exec_byte_code+888>, 0x59a508 <exec_byte_code+7688>, 0x59a538 <exec_byte_code+7736>, 
          0x59a568 <exec_byte_code+7784>, 0x59a598 <exec_byte_code+7832>, 0x59a5c8 <exec_byte_code+7880>, 0x59a5f8 <exec_byte_code+7928>, 0x598960 <exec_byte_code+608>, 
          0x598a78 <exec_byte_code+888>, 0x59a628 <exec_byte_code+7976>, 0x59a670 <exec_byte_code+8048>, 0x59a6a0 <exec_byte_code+8096>, 0x59a6d0 <exec_byte_code+8144>, 
          0x59a710 <exec_byte_code+8208>, 0x59a750 <exec_byte_code+8272>, 0x599e58 <exec_byte_code+5976>, 0x599e80 <exec_byte_code+6016>, 0x59af40 <exec_byte_code+10304>, 
          0x59af80 <exec_byte_code+10368>, 0x59ae70 <exec_byte_code+10096>, 0x59aea0 <exec_byte_code+10144>, 0x598a78 <exec_byte_code+888>, 0x59a3e8 <exec_byte_code+7400>, 
          0x598b60 <exec_byte_code+1120>, 0x59a128 <exec_byte_code+6696>, 0x598c10 <exec_byte_code+1296>, 0x598cc0 <exec_byte_code+1472>, 0x598d68 <exec_byte_code+1640>, 
          0x599fe8 <exec_byte_code+6376>, 0x59a3c0 <exec_byte_code+7360>, 0x59a2f0 <exec_byte_code+7152>, 0x59a328 <exec_byte_code+7208>, 0x59a360 <exec_byte_code+7264>, 
          0x5999b8 <exec_byte_code+4792>, 0x599a88 <exec_byte_code+5000>, 0x599b00 <exec_byte_code+5120>, 0x599b50 <exec_byte_code+5200>, 0x599b90 <exec_byte_code+5264>, 
          0x599050 <exec_byte_code+2384>, 0x598b38 <exec_byte_code+1080>, 0x59aed0 <exec_byte_code+10192>, 0x59af10 <exec_byte_code+10256>, 0x59ac28 <exec_byte_code+9512>, 
          0x59ac58 <exec_byte_code+9560>, 0x59ac88 <exec_byte_code+9608>, 0x59acb8 <exec_byte_code+9656>, 0x59acf8 <exec_byte_code+9720>, 0x59ad38 <exec_byte_code+9784>, 
          0x59ad78 <exec_byte_code+9848>, 0x59adb8 <exec_byte_code+9912>, 0x59aa40 <exec_byte_code+9024>, 0x59aa80 <exec_byte_code+9088>, 0x59aac0 <exec_byte_code+9152>, 
          0x59aaf0 <exec_byte_code+9200>, 0x59ab30 <exec_byte_code+9264>, 0x59ab70 <exec_byte_code+9328>, 0x59abb0 <exec_byte_code+9392>, 0x59abf0 <exec_byte_code+9456>, 
          0x59aa08 <exec_byte_code+8968>, 0x59a780 <exec_byte_code+8320>, 0x59a070 <exec_byte_code+6512>, 0x59a0c0 <exec_byte_code+6592>, 0x598a78 <exec_byte_code+888>, 
          0x598e10 <exec_byte_code+1808>, 0x598ea0 <exec_byte_code+1952>, 0x598f30 <exec_byte_code+2096>, 0x598fc0 <exec_byte_code+2240>, 0x599dc8 <exec_byte_code+5832>, 
          0x5993c0 <exec_byte_code+3264>, 0x5996c8 <exec_byte_code+4040>, 0x59a860 <exec_byte_code+8544>, 0x599c90 <exec_byte_code+5520>, 0x599ce0 <exec_byte_code+5600>, 
          0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x599d40 <exec_byte_code+5696>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 
          0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 
          0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x599d90 <exec_byte_code+5776> <repeats 64 times>}
        count = 10
        op = <optimized out>
        vectorp = 0x1443438
        stack = {pc = 0x3631990 "\210\320\321!).\006\207", byte_string = 21113700, byte_string_start = 0x3631960 "\b\205\067", next = 0x0}
        top = 0x7fff02b4fa68
        result = <optimized out>
        type = <optimized out>
#30 0x0000000000563732 in funcall_lambda (fun=57191557, nargs=2, arg_vector=0x7fff02b4fcc8) at eval.c:2921
        val = <optimized out>
        syms_left = 0
        lexenv = 0
        i = <optimized out>
        optional = <optimized out>
        rest = <optimized out>
#31 0x0000000000563b13 in Ffuncall (nargs=86946816, args=0x368ac80) at eval.c:2754
        numargs = 2
        val = 333
        internal_args = 0x7fff02b4fcc8
        count = 7
#32 0x0000000000564059 in funcall_nil (nargs=<optimized out>, args=<optimized out>) at eval.c:2332
No locals.
#33 0x000000000056205d in run_hook_with_args (nargs=3, args=0x7fff02b4fcc0, funcall=0x564050 <funcall_nil>) at eval.c:2509
        global_vals = <optimized out>
        sym = 50784
        val = 61477811
        ret = 0
#34 0x000000000056282e in run_hook_with_args (funcall=<optimized out>, args=<optimized out>, nargs=<optimized out>) at eval.c:2459
No locals.
#35 Frun_hook_with_args (args=0x7fff02b4fcc0, nargs=3) at eval.c:2374
        args = 0x7fff02b4fcc0
        nargs = 3
#36 run_hook_with_args_2 (hook=hook@entry=50784, arg1=arg1@entry=58591413, arg2=arg2@entry=1553398) at eval.c:2530
No locals.
#37 0x0000000000432465 in run_window_scroll_functions (window=58591413, startp=...) at xdisp.c:15110
No locals.
#38 0x000000000046443a in redisplay_window (window=58591413, just_this_one_p=false, just_this_one_p@entry=true) at xdisp.c:16382
        new_vpos = 391173
        startp = {charpos = 333, bytepos = 334}
        it = {window = 58591413, w = 0x37e08b0, f = 0x1224650, method = GET_FROM_BUFFER, stop_charpos = 391173, prev_stop = 391082, base_level_stop = 391082, end_charpos = 391173, s = 0x0, 
          string_nchars = 0, redisplay_end_trigger_charpos = 0, multibyte_p = true, header_line_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, 
          from_disp_prop_p = false, ellipsis_p = false, avoid_cursor_p = false, dp = 0x0, dpvec = 0x0, dpend = 0x0, dpvec_char_len = 0, dpvec_face_id = 0, saved_face_id = 0, ctl_chars = {
            0 <repeats 16 times>}, start = {pos = {charpos = 388349, bytepos = 388357}, overlay_string_index = -1, string_pos = {charpos = -1, bytepos = -1}, dpvec_index = -1}, current = {
            pos = {charpos = 391173, bytepos = 391181}, overlay_string_index = -1, string_pos = {charpos = -1, bytepos = -1}, dpvec_index = -1}, n_overlay_strings = 0, 
          overlay_strings_charpos = 391173, overlay_strings = {0 <repeats 16 times>}, string_overlays = {0 <repeats 16 times>}, string = 0, from_overlay = 0, stack = {{string = 0, 
              string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = {stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, 
                reversed_p = false, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0}, face_id = 0, u = {image = {object = 0, slice = {x = 0, y = 0, width = 0, height = 0}, 
                  image_id = 0}, stretch = {object = 0}, xwidget = {object = 0}}, position = {charpos = 0, bytepos = 0}, current = {pos = {charpos = 0, bytepos = 0}, overlay_string_index = 0, 
                string_pos = {charpos = 0, bytepos = 0}, dpvec_index = 0}, from_overlay = 0, area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, 
              multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, 
              from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = 0, font_height = 0}, {string = 0, string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, 
              base_level_stop = 0, cmp_it = {stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, 
                width = 0}, face_id = 0, u = {image = {object = 0, slice = {x = 0, y = 0, width = 0, height = 0}, image_id = 0}, stretch = {object = 0}, xwidget = {object = 0}}, position = {
                charpos = 0, bytepos = 0}, current = {pos = {charpos = 0, bytepos = 0}, overlay_string_index = 0, string_pos = {charpos = 0, bytepos = 0}, dpvec_index = 0}, from_overlay = 0, 
              area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, 
              display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = 0, font_height = 0}, {string = 0, 
              string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = {stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, 
                reversed_p = false, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0}, face_id = 0, u = {image = {object = 0, slice = {x = 0, y = 0, width = 0, height = 0}, 
                  image_id = 0}, stretch = {object = 0}, xwidget = {object = 0}}, position = {charpos = 0, bytepos = 0}, current = {pos = {charpos = 0, bytepos = 0}, overlay_string_index = 0, 
                string_pos = {charpos = 0, bytepos = 0}, dpvec_index = 0}, from_overlay = 0, area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, 
              multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, 
              from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = 0, font_height = 0}, {string = 0, string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, 
              base_level_stop = 0, cmp_it = {stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, 
                width = 0}, face_id = 0, u = {image = {object = 0, slice = {x = 0, y = 0, width = 0, height = 0}, image_id = 0}, stretch = {object = 0}, xwidget = {object = 0}}, position = {
                charpos = 0, bytepos = 0}, current = {pos = {charpos = 0, bytepos = 0}, overlay_string_index = 0, string_pos = {charpos = 0, bytepos = 0}, dpvec_index = 0}, from_overlay = 0, 
              area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, 
              display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = 0, font_height = 0}, {string = 0, 
              string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = {stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, 
                reversed_p = false, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0}, face_id = 0, u = {image = {object = 0, slice = {x = 0, y = 0, width = 0, height = 0}, 
                  image_id = 0}, stretch = {object = 0}, xwidget = {object = 0}}, position = {charpos = 0, bytepos = 0}, current = {pos = {charpos = 0, bytepos = 0}, overlay_string_index = 0, 
                string_pos = {charpos = 0, bytepos = 0}, dpvec_index = 0}, from_overlay = 0, area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, 
              multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, 
              from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = 0, font_height = 0}}, sp = 0, selective = 0, what = IT_EOB, face_id = 0, 
          selective_display_ellipsis_p = true, ctl_arrow_p = true, face_box_p = false, start_of_box_run_p = false, end_of_box_run_p = false, overlay_strings_at_end_processed_p = true, 
          ignore_overlay_strings_at_pos_p = false, glyph_not_available_p = false, starts_in_middle_of_char_p = false, face_before_selective_p = false, constrain_row_ascent_descent_p = false, 
          line_wrap = WINDOW_WRAP, base_face_id = 0, c = 32, len = 1, cmp_it = {stop_pos = 391171, id = -1, ch = -2, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, charpos = 0, 
            nchars = 0, nbytes = 0, from = 0, to = 0, width = 0}, char_to_display = 32, glyphless_method = GLYPHLESS_DISPLAY_THIN_SPACE, image_id = 0, xwidget = 0x0, slice = {x = 0, y = 0, 
            width = 0, height = 0}, space_width = 0, voffset = 0, tab_width = 4, font_height = 0, object = 58622773, position = {charpos = 391173, bytepos = 391181}, truncation_pixel_width = 0, 
          continuation_pixel_width = 6, first_visible_x = 0, last_visible_x = 480, last_visible_y = 663, extra_line_spacing = 1, max_extra_line_spacing = 1, override_ascent = -1, 
          override_descent = 0, override_boff = 0, glyph_row = 0x3b39c30, area = TEXT_AREA, nglyphs = 1, pixel_width = 6, ascent = 11, descent = 3, max_ascent = 11, max_descent = 3, 
          phys_ascent = 0, phys_descent = 0, max_phys_ascent = 11, max_phys_descent = 2, current_x = 12, continuation_lines_width = 0, eol_pos = {charpos = 0, bytepos = 0}, current_y = 644, 
          first_vpos = 0, vpos = 46, hpos = 2, left_user_fringe_bitmap = 0, right_user_fringe_bitmap = 0, left_user_fringe_face_id = 0, right_user_fringe_face_id = 0, bidi_p = true, bidi_it = {
            bytepos = 391181, charpos = 391173, ch = -1, nchars = 1, ch_len = 1, type = NEUTRAL_B, type_after_wn = NEUTRAL_B, orig_type = NEUTRAL_B, resolved_level = 0 '\000', 
            isolate_level = 0 '\000', invalid_levels = 0, invalid_isolates = 0, prev = {charpos = 391172, type = UNKNOWN_BT, orig_type = NEUTRAL_WS}, last_strong = {charpos = 391168, 
              type = UNKNOWN_BT, orig_type = UNKNOWN_BT}, next_for_neutral = {charpos = 390500, type = UNKNOWN_BT, orig_type = UNKNOWN_BT}, prev_for_neutral = {charpos = 391173, 
              type = STRONG_L, orig_type = NEUTRAL_WS}, next_for_ws = {charpos = -1, type = UNKNOWN_BT, orig_type = UNKNOWN_BT}, bracket_pairing_pos = -1, bracket_enclosed_type = UNKNOWN_BT, 
            next_en_pos = 0, next_en_type = UNKNOWN_BT, sos = L2R, scan_dir = 1, disp_pos = 391173, disp_prop = 0, stack_idx = 0, level_stack = {{next_for_neutral_pos = 0, 
                next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000'} <repeats 128 times>}, string = {lstring = 0, s = 0x0, schars = 0, 
              bufpos = 0, from_disp_str = false, unibyte = false}, w = 0x37e08b0, paragraph_dir = L2R, separator_limit = -1, first_elt = false, new_paragraph = false, frame_window_p = true}, 
          paragraph_embedding = NEUTRAL_DIR}
        temp_scroll_step = true
        rc = 0
        last_line_misfit = false
        itdata = 0x7fff02b4fe10
#39 0x0000000000467a1e in redisplay_window_1 (window=window@entry=58591413) at xdisp.c:14454
No locals.
#40 0x000000000056260c in internal_condition_case_1 (bfun=0x4679f0 <redisplay_window_1>, arg=58591413, handlers=<optimized out>, hfun=0x42cf60 <redisplay_window_error>) at eval.c:1333
        val = 333
        c = <optimized out>
#41 0x0000000000456ad0 in redisplay_internal () at xdisp.c:14079
        match_p = 176
#42 0x00000000004fa2b3 in read_char (commandflag=86946816, commandflag@entry=1, map=86617088, map@entry=86601331, prev_event=334, used_mouse_menu=0x0, used_mouse_menu@entry=0x7fff02b53dcb, 
    end_time=0x143ba01, end_time@entry=0x0) at keyboard.c:2477
        local_getcjmp = {{__jmpbuf = {58622773, 1564694, 29472, 1564690, 391168, 5988911, 391172, 66918760228998144}, __mask_was_saved = 45431872, __saved_mask = {__val = {1564694, 
                140733238819904, 29472, 391181, 18446744073709551615, 58622773, 5597497, 3, 401584, 58622768, 3743, 12620597, 391173, 1564694, 58622773, 0}}}}
        save_jump = {{__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = {__val = {0 <repeats 16 times>}}}}
        save = 13951632
        previous_echo_area_message = 0
        also_record = 0
        reread = false
        recorded = false
        polling_stopped_here = false
#43 0x00000000004fca76 in read_key_sequence (keybuf=keybuf@entry=0x7fff02b53ea0, prompt=prompt@entry=0, dont_downcase_last=dont_downcase_last@entry=false, 
    can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false, bufsize=30) at keyboard.c:9063
        interrupted_kboard = 0xd4e290
        interrupted_frame = 0x1224650
        key = <optimized out>
        used_mouse_menu = false
        echo_local_start = 0
        last_real_key_start = <optimized out>
        keys_local_start = <optimized out>
        new_binding = <optimized out>
        t = <optimized out>
        echo_start = 0
        keys_start = 0
        current_binding = 86601331
        first_event = 0
        first_unbound = 31
        mock_input = 0
        fkey = {parent = 17130995, map = 17130995, start = 0, end = 0}
        keytran = {parent = 12570179, map = 12570179, start = 0, end = 0}
        indec = {parent = 17131123, map = 17131123, start = 0, end = 0}
        shift_translated = false
        delayed_switch_frame = 0
        original_uppercase = 0
        original_uppercase_position = -1
        dummyflag = false
        starting_buffer = 0x37e8330
        fake_prefixed_keys = 0
#44 0x00000000004fe6b6 in command_loop_1 () at keyboard.c:1365
        cmd = <optimized out>
        keybuf = {54, 78, 202, -6202091921070732288, 2822930839, -6202091921070732288, 9955464, 5377136, 73708083, 140733238820720, 73708083, 140733238821408, 0, 5652260, 317296, 73708083, 
          8756772, 5377136, 12340336, -6202091921070732288, 73708083, 5197970, 140733238820720, 0, 0, 5198303, 140733238821376, 5579137, 28416, 96}
        i = <optimized out>
        prev_modiff = 46990
        prev_buffer = 0x37e8330
#45 0x0000000000562686 in internal_condition_case (bfun=bfun@entry=0x4fe4b0 <command_loop_1>, handlers=handlers@entry=19056, hfun=hfun@entry=0x4f50c0 <cmd_error>) at eval.c:1309
        val = 333
        c = <optimized out>
#46 0x00000000004f06ec in command_loop_2 (ignore=ignore@entry=0) at keyboard.c:1107
        val = 333
#47 0x00000000005626eb in internal_catch (tag=tag@entry=45840, func=func@entry=0x4f06d0 <command_loop_2>, arg=arg@entry=0) at eval.c:1074
        val = 333
        c = <optimized out>
#48 0x00000000004f06a9 in command_loop () at keyboard.c:1086
No locals.
#49 0x00000000004f4cd7 in recursive_edit_1 () at keyboard.c:692
        val = <optimized out>
#50 0x00000000004f4ff0 in Frecursive_edit () at keyboard.c:763
        buffer = <optimized out>
#51 0x0000000000418dce in main (argc=1, argv=0x7fff02b54228) at emacs.c:1626
        dummy = 140069625578752
        stack_bottom_variable = 2 '\002'
        skip_args = 0
        rlim = {rlim_cur = 8720000, rlim_max = 18446744073709551615}
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x0
#0  0x00007f6478ab875b in raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
        resultvar = 0
        pid = <optimized out>
#1  0x00000000004f0184 in terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40) at emacs.c:381
No locals.
#2  0x0000000000508fd3 in emacs_abort () at sysdep.c:2247
No locals.
#3  0x000000000056463b in Fsignal (error_symbol=error_symbol@entry=28656, data=86599795) at eval.c:1478
        conditions = <optimized out>
        string = <optimized out>
        real_error_symbol = 28656
        clause = <optimized out>
        h = <optimized out>
#4  0x0000000000564649 in xsignal (error_symbol=error_symbol@entry=28656, data=<optimized out>) at eval.c:1577
No locals.
#5  0x0000000000565157 in xsignal1 (error_symbol=error_symbol@entry=28656, arg=<optimized out>) at eval.c:1592
No locals.
#6  0x0000000000533fee in compile_pattern_1 (posix=<optimized out>, translate=0, pattern=<optimized out>, cp=0xb935d0 <searchbufs+6480>) at search.c:154
        val = 0x600576 "Regular expression too big"
        old = 0
#7  compile_pattern (pattern=pattern@entry=61362260, regp=regp@entry=0x0, translate=translate@entry=0, posix=posix@entry=false, multibyte=<optimized out>) at search.c:237
        cp = 0xb935d0 <searchbufs+6480>
        cpp = <optimized out>
#8  0x000000000053619d in fast_string_match_internal (regexp=regexp@entry=61362260, string=string@entry=61914372, table=table@entry=0) at search.c:471
        val = 0
        bufp = <optimized out>
#9  0x000000000051dd61 in fast_string_match (string=61914372, regexp=61362260) at lisp.h:4010
No locals.
#10 Ffind_file_name_handler (filename=filename@entry=61914372, operation=operation@entry=19872) at fileio.c:292
        operations = 0
        chain = 61546355
        inhibited_handlers = 0
        result = 0
        pos = -1
#11 0x000000000051f3c0 in Fexpand_file_name (name=61914372, default_directory=default_directory@entry=0) at fileio.c:809
        nm = <optimized out>
        nmlim = <optimized out>
        newdir = <optimized out>
        newdirlim = <optimized out>
        target = <optimized out>
        tlen = <optimized out>
        pw = <optimized out>
        length = <optimized out>
        nbytes = <optimized out>
        handler = <optimized out>
        result = <optimized out>
        handled_name = <optimized out>
        multibyte = <optimized out>
        hdir = <optimized out>
        sa_avail = 16384
        sa_must_free = false
#12 0x0000000000524298 in Fdo_auto_save (no_message=<optimized out>, no_message@entry=44448, current_only=current_only@entry=0) at fileio.c:5521
        listfile = <optimized out>
        old = 0x37e8330
        tail = <optimized out>
        auto_saved = false
        do_handled_files = <optimized out>
        oquit = 0
        stream = 0x0
        orig_minibuffer_auto_raise = false
        old_message_p = false
        auto_save_unwind = {
          stream = 0x7f647864bf6e, 
          auto_raise = 40
        }
#13 0x00000000004effa0 in shut_down_emacs (sig=sig@entry=11, stuff=stuff@entry=0) at emacs.c:2000
No locals.
#14 0x00000000004f0155 in terminate_due_to_signal (sig=sig@entry=11, backtrace_limit=backtrace_limit@entry=40) at emacs.c:365
No locals.
#15 0x0000000000507c7e in handle_fatal_signal (sig=sig@entry=11) at sysdep.c:1601
No locals.
#16 0x0000000000507e33 in deliver_thread_signal (sig=sig@entry=11, handler=0x507c70 <handle_fatal_signal>) at sysdep.c:1575
No locals.
#17 0x0000000000507ebc in deliver_fatal_thread_signal (sig=11) at sysdep.c:1613
No locals.
#18 handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>) at sysdep.c:1695
        fatal = <optimized out>
#19 <signal handler called>
No locals.
#20 mark_object (arg=<optimized out>) at alloc.c:6446
        ptr = 0x5ea9170
        obj = <optimized out>
        po = <optimized out>
        cdr_count = <optimized out>
#21 0x000000000054bb63 in mark_object (arg=<optimized out>) at alloc.c:6539
        obj = <optimized out>
        po = <optimized out>
        cdr_count = 2174
#22 0x000000000054d28e in mark_maybe_pointer (p=0x52eb480) at alloc.c:4845
        obj = <optimized out>
        m = <optimized out>
#23 mark_memory (end=0x7fff02b540a8, start=<optimized out>) at alloc.c:4894
        pp = 0x7fff02b514e8 "\200\264.\005"
#24 mark_stack (end=0x7fff02b4f898) at alloc.c:5038
No locals.
#25 garbage_collect_1 (end=0x7fff02b4f898) at alloc.c:5756
        nextb = <optimized out>
        i = <optimized out>
        retval = <optimized out>
        stack_top_variable = 0 '\000'
        message_p = false
        tot_before = 0
        total = {58591408, 0, 0, 8, 2, 5652410, 374496, 11808, 0, -6202091921070732288, 8}
#26 Fgarbage_collect () at alloc.c:5979
        end = 0x7fff02b4f898
#27 0x00000000005639cc in maybe_gc () at lisp.h:4656
No locals.
#28 Ffuncall (nargs=86946816, args=0x7fff02b4fa68) at eval.c:2643
        numargs = 1
        val = 333
        internal_args = 0x7fff02b4fa70
        count = 17
#29 0x00000000005988f3 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=args_template@entry=0, nargs=nargs@entry=0, 
    args=<optimized out>, args@entry=0x0) at bytecode.c:880
        targets = {0x598a78 <exec_byte_code+888>, 0x59a050 <exec_byte_code+6480>, 0x59a058 <exec_byte_code+6488>, 0x59a060 <exec_byte_code+6496>, 0x598838 <exec_byte_code+312>, 
          0x598840 <exec_byte_code+320>, 0x599be0 <exec_byte_code+5344>, 0x599c30 <exec_byte_code+5424>, 0x59a068 <exec_byte_code+6504>, 0x598b08 <exec_byte_code+1032>, 
          0x598ac0 <exec_byte_code+960>, 0x598b10 <exec_byte_code+1040>, 0x598a08 <exec_byte_code+776>, 0x598a10 <exec_byte_code+784>, 0x59a110 <exec_byte_code+6672>, 
          0x598ac8 <exec_byte_code+968>, 0x598b18 <exec_byte_code+1048>, 0x599ec0 <exec_byte_code+6080>, 0x59a320 <exec_byte_code+7200>, 0x599f08 <exec_byte_code+6152>, 
          0x598990 <exec_byte_code+656>, 0x598990 <exec_byte_code+656>, 0x59a2d8 <exec_byte_code+7128>, 0x599ec8 <exec_byte_code+6088>, 0x599f38 <exec_byte_code+6200>, 
          0x599f40 <exec_byte_code+6208>, 0x599f90 <exec_byte_code+6288>, 0x598b20 <exec_byte_code+1056>, 0x598880 <exec_byte_code+384>, 0x598880 <exec_byte_code+384>, 
          0x599ef0 <exec_byte_code+6128>, 0x599f10 <exec_byte_code+6160>, 0x599f88 <exec_byte_code+6280>, 0x599f98 <exec_byte_code+6296>, 0x599fa0 <exec_byte_code+6304>, 
          0x598b28 <exec_byte_code+1064>, 0x5988c8 <exec_byte_code+456>, 0x5988d0 <exec_byte_code+464>, 0x599f48 <exec_byte_code+6216>, 0x599f60 <exec_byte_code+6240>, 
          0x599fd8 <exec_byte_code+6360>, 0x599fd0 <exec_byte_code+6352>, 0x599fe0 <exec_byte_code+6368>, 0x598b30 <exec_byte_code+1072>, 0x598918 <exec_byte_code+536>, 
          0x598920 <exec_byte_code+544>, 0x598af0 <exec_byte_code+1008>, 0x599fa8 <exec_byte_code+6312>, 0x599ad0 <exec_byte_code+5072>, 0x5999f0 <exec_byte_code+4848>, 
          0x59a040 <exec_byte_code+6464>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 
          0x598a78 <exec_byte_code+888>, 0x5990b0 <exec_byte_code+2480>, 0x599140 <exec_byte_code+2624>, 0x599188 <exec_byte_code+2696>, 0x5991d0 <exec_byte_code+2768>, 
          0x599220 <exec_byte_code+2848>, 0x59a290 <exec_byte_code+7056>, 0x59a1d0 <exec_byte_code+6864>, 0x599268 <exec_byte_code+2920>, 0x59a250 <exec_byte_code+6992>, 
          0x59a210 <exec_byte_code+6928>, 0x5992a0 <exec_byte_code+2976>, 0x5992e0 <exec_byte_code+3040>, 0x599310 <exec_byte_code+3088>, 0x599350 <exec_byte_code+3152>, 
          0x599388 <exec_byte_code+3208>, 0x599410 <exec_byte_code+3344>, 0x599440 <exec_byte_code+3392>, 0x599480 <exec_byte_code+3456>, 0x5994c0 <exec_byte_code+3520>, 
          0x5994f0 <exec_byte_code+3568>, 0x599520 <exec_byte_code+3616>, 0x599560 <exec_byte_code+3680>, 0x5995a0 <exec_byte_code+3744>, 0x5995e0 <exec_byte_code+3808>, 
          0x599620 <exec_byte_code+3872>, 0x599658 <exec_byte_code+3928>, 0x599690 <exec_byte_code+3984>, 0x599718 <exec_byte_code+4120>, 0x599760 <exec_byte_code+4192>, 
          0x5997a8 <exec_byte_code+4264>, 0x599880 <exec_byte_code+4480>, 0x5997f8 <exec_byte_code+4344>, 0x599840 <exec_byte_code+4416>, 0x5998c0 <exec_byte_code+4544>, 
          0x599900 <exec_byte_code+4608>, 0x599938 <exec_byte_code+4664>, 0x599980 <exec_byte_code+4736>, 0x59a960 <exec_byte_code+8800>, 0x59a998 <exec_byte_code+8856>, 
          0x59a9d0 <exec_byte_code+8912>, 0x59a7c0 <exec_byte_code+8384>, 0x598960 <exec_byte_code+608>, 0x59a800 <exec_byte_code+8448>, 0x59a830 <exec_byte_code+8496>, 
          0x59a8b0 <exec_byte_code+8624>, 0x59a8f0 <exec_byte_code+8688>, 0x59a930 <exec_byte_code+8752>, 0x59a440 <exec_byte_code+7488>, 0x59a470 <exec_byte_code+7536>, 
          0x59a4a0 <exec_byte_code+7584>, 0x59a4d8 <exec_byte_code+7640>, 0x598a78 <exec_byte_code+888>, 0x59a508 <exec_byte_code+7688>, 0x59a538 <exec_byte_code+7736>, 
          0x59a568 <exec_byte_code+7784>, 0x59a598 <exec_byte_code+7832>, 0x59a5c8 <exec_byte_code+7880>, 0x59a5f8 <exec_byte_code+7928>, 0x598960 <exec_byte_code+608>, 
          0x598a78 <exec_byte_code+888>, 0x59a628 <exec_byte_code+7976>, 0x59a670 <exec_byte_code+8048>, 0x59a6a0 <exec_byte_code+8096>, 0x59a6d0 <exec_byte_code+8144>, 
          0x59a710 <exec_byte_code+8208>, 0x59a750 <exec_byte_code+8272>, 0x599e58 <exec_byte_code+5976>, 0x599e80 <exec_byte_code+6016>, 0x59af40 <exec_byte_code+10304>, 
          0x59af80 <exec_byte_code+10368>, 0x59ae70 <exec_byte_code+10096>, 0x59aea0 <exec_byte_code+10144>, 0x598a78 <exec_byte_code+888>, 0x59a3e8 <exec_byte_code+7400>, 
          0x598b60 <exec_byte_code+1120>, 0x59a128 <exec_byte_code+6696>, 0x598c10 <exec_byte_code+1296>, 0x598cc0 <exec_byte_code+1472>, 0x598d68 <exec_byte_code+1640>, 
          0x599fe8 <exec_byte_code+6376>, 0x59a3c0 <exec_byte_code+7360>, 0x59a2f0 <exec_byte_code+7152>, 0x59a328 <exec_byte_code+7208>, 0x59a360 <exec_byte_code+7264>, 
          0x5999b8 <exec_byte_code+4792>, 0x599a88 <exec_byte_code+5000>, 0x599b00 <exec_byte_code+5120>, 0x599b50 <exec_byte_code+5200>, 0x599b90 <exec_byte_code+5264>, 
          0x599050 <exec_byte_code+2384>, 0x598b38 <exec_byte_code+1080>, 0x59aed0 <exec_byte_code+10192>, 0x59af10 <exec_byte_code+10256>, 0x59ac28 <exec_byte_code+9512>, 
          0x59ac58 <exec_byte_code+9560>, 0x59ac88 <exec_byte_code+9608>, 0x59acb8 <exec_byte_code+9656>, 0x59acf8 <exec_byte_code+9720>, 0x59ad38 <exec_byte_code+9784>, 
          0x59ad78 <exec_byte_code+9848>, 0x59adb8 <exec_byte_code+9912>, 0x59aa40 <exec_byte_code+9024>, 0x59aa80 <exec_byte_code+9088>, 0x59aac0 <exec_byte_code+9152>, 
          0x59aaf0 <exec_byte_code+9200>, 0x59ab30 <exec_byte_code+9264>, 0x59ab70 <exec_byte_code+9328>, 0x59abb0 <exec_byte_code+9392>, 0x59abf0 <exec_byte_code+9456>, 
          0x59aa08 <exec_byte_code+8968>, 0x59a780 <exec_byte_code+8320>, 0x59a070 <exec_byte_code+6512>, 0x59a0c0 <exec_byte_code+6592>, 0x598a78 <exec_byte_code+888>, 
          0x598e10 <exec_byte_code+1808>, 0x598ea0 <exec_byte_code+1952>, 0x598f30 <exec_byte_code+2096>, 0x598fc0 <exec_byte_code+2240>, 0x599dc8 <exec_byte_code+5832>, 
          0x5993c0 <exec_byte_code+3264>, 0x5996c8 <exec_byte_code+4040>, 0x59a860 <exec_byte_code+8544>, 0x599c90 <exec_byte_code+5520>, 0x599ce0 <exec_byte_code+5600>, 
          0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x599d40 <exec_byte_code+5696>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 
          0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 
          0x598a78 <exec_byte_code+888>, 0x598a78 <exec_byte_code+888>, 0x599d90 <exec_byte_code+5776> <repeats 64 times>}
        count = 10
        op = <optimized out>
        vectorp = 0x1443438
        stack = {
          pc = 0x3631990 "\210\320\321!).\006\207", 
          byte_string = 21113700, 
          byte_string_start = 0x3631960 "\b\205\067", 
          next = 0x0
        }
        top = 0x7fff02b4fa68
        result = <optimized out>
        type = <optimized out>
#30 0x0000000000563732 in funcall_lambda (fun=57191557, nargs=2, arg_vector=0x7fff02b4fcc8) at eval.c:2921
        val = <optimized out>
        syms_left = 0
        lexenv = 0
        i = <optimized out>
        optional = <optimized out>
        rest = <optimized out>
#31 0x0000000000563b13 in Ffuncall (nargs=86946816, args=0x368ac80) at eval.c:2754
        numargs = 2
        val = 333
        internal_args = 0x7fff02b4fcc8
        count = 7
#32 0x0000000000564059 in funcall_nil (nargs=<optimized out>, args=<optimized out>) at eval.c:2332
No locals.
#33 0x000000000056205d in run_hook_with_args (nargs=3, args=0x7fff02b4fcc0, funcall=0x564050 <funcall_nil>) at eval.c:2509
        global_vals = <optimized out>
        sym = 50784
        val = 61477811
        ret = 0
#34 0x000000000056282e in run_hook_with_args (funcall=<optimized out>, args=<optimized out>, nargs=<optimized out>) at eval.c:2459
No locals.
#35 Frun_hook_with_args (args=0x7fff02b4fcc0, nargs=3) at eval.c:2374
        args = 0x7fff02b4fcc0
        nargs = 3
#36 run_hook_with_args_2 (hook=hook@entry=50784, arg1=arg1@entry=58591413, arg2=arg2@entry=1553398) at eval.c:2530
No locals.
#37 0x0000000000432465 in run_window_scroll_functions (window=58591413, startp=...) at xdisp.c:15110
No locals.
#38 0x000000000046443a in redisplay_window (window=58591413, just_this_one_p=false, just_this_one_p@entry=true) at xdisp.c:16382
        new_vpos = 391173
        startp = {
          charpos = 333, 
          bytepos = 334
        }
        it = {
          window = 58591413, 
          w = 0x37e08b0, 
          f = 0x1224650, 
          method = GET_FROM_BUFFER, 
          stop_charpos = 391173, 
          prev_stop = 391082, 
          base_level_stop = 391082, 
          end_charpos = 391173, 
          s = 0x0, 
          string_nchars = 0, 
          redisplay_end_trigger_charpos = 0, 
          multibyte_p = true, 
          header_line_p = false, 
          string_from_display_prop_p = false, 
          string_from_prefix_prop_p = false, 
          from_disp_prop_p = false, 
          ellipsis_p = false, 
          avoid_cursor_p = false, 
          dp = 0x0, 
          dpvec = 0x0, 
          dpend = 0x0, 
          dpvec_char_len = 0, 
          dpvec_face_id = 0, 
          saved_face_id = 0, 
          ctl_chars = {0 <repeats 16 times>}, 
          start = {
            pos = {
              charpos = 388349, 
              bytepos = 388357
            }, 
            overlay_string_index = -1, 
            string_pos = {
              charpos = -1, 
              bytepos = -1
            }, 
            dpvec_index = -1
          }, 
          current = {
            pos = {
              charpos = 391173, 
              bytepos = 391181
            }, 
            overlay_string_index = -1, 
            string_pos = {
              charpos = -1, 
              bytepos = -1
            }, 
            dpvec_index = -1
          }, 
          n_overlay_strings = 0, 
          overlay_strings_charpos = 391173, 
          overlay_strings = {0 <repeats 16 times>}, 
          string_overlays = {0 <repeats 16 times>}, 
          string = 0, 
          from_overlay = 0, 
          stack = {{
              string = 0, 
              string_nchars = 0, 
              end_charpos = 0, 
              stop_charpos = 0, 
              prev_stop = 0, 
              base_level_stop = 0, 
              cmp_it = {
                stop_pos = 0, 
                id = 0, 
                ch = 0, 
                rule_idx = 0, 
                lookback = 0, 
                nglyphs = 0, 
                reversed_p = false, 
                charpos = 0, 
                nchars = 0, 
                nbytes = 0, 
                from = 0, 
                to = 0, 
                width = 0
              }, 
              face_id = 0, 
              u = {
                image = {
                  object = 0, 
                  slice = {
                    x = 0, 
                    y = 0, 
                    width = 0, 
                    height = 0
                  }, 
                  image_id = 0
                }, 
                stretch = {
                  object = 0
                }, 
                xwidget = {
                  object = 0
                }
              }, 
              position = {
                charpos = 0, 
                bytepos = 0
              }, 
              current = {
                pos = {
                  charpos = 0, 
                  bytepos = 0
                }, 
                overlay_string_index = 0, 
                string_pos = {
                  charpos = 0, 
                  bytepos = 0
                }, 
                dpvec_index = 0
              }, 
              from_overlay = 0, 
              area = LEFT_MARGIN_AREA, 
              method = GET_FROM_BUFFER, 
              paragraph_embedding = NEUTRAL_DIR, 
              multibyte_p = false, 
              string_from_display_prop_p = false, 
              string_from_prefix_prop_p = false, 
              display_ellipsis_p = false, 
              avoid_cursor_p = false, 
              bidi_p = false, 
              from_disp_prop_p = false, 
              line_wrap = TRUNCATE, 
              voffset = 0, 
              space_width = 0, 
              font_height = 0
            }, {
              string = 0, 
              string_nchars = 0, 
              end_charpos = 0, 
              stop_charpos = 0, 
              prev_stop = 0, 
              base_level_stop = 0, 
              cmp_it = {
                stop_pos = 0, 
                id = 0, 
                ch = 0, 
                rule_idx = 0, 
                lookback = 0, 
                nglyphs = 0, 
                reversed_p = false, 
                charpos = 0, 
                nchars = 0, 
                nbytes = 0, 
                from = 0, 
                to = 0, 
                width = 0
              }, 
              face_id = 0, 
              u = {
                image = {
                  object = 0, 
                  slice = {
                    x = 0, 
                    y = 0, 
                    width = 0, 
                    height = 0
                  }, 
                  image_id = 0
                }, 
                stretch = {
                  object = 0
                }, 
                xwidget = {
                  object = 0
                }
              }, 
              position = {
                charpos = 0, 
                bytepos = 0
              }, 
              current = {
                pos = {
                  charpos = 0, 
                  bytepos = 0
                }, 
                overlay_string_index = 0, 
                string_pos = {
                  charpos = 0, 
                  bytepos = 0
                }, 
                dpvec_index = 0
              }, 
              from_overlay = 0, 
              area = LEFT_MARGIN_AREA, 
              method = GET_FROM_BUFFER, 
              paragraph_embedding = NEUTRAL_DIR, 
              multibyte_p = false, 
              string_from_display_prop_p = false, 
              string_from_prefix_prop_p = false, 
              display_ellipsis_p = false, 
              avoid_cursor_p = false, 
              bidi_p = false, 
              from_disp_prop_p = false, 
              line_wrap = TRUNCATE, 
              voffset = 0, 
              space_width = 0, 
              font_height = 0
            }, {
              string = 0, 
              string_nchars = 0, 
              end_charpos = 0, 
              stop_charpos = 0, 
              prev_stop = 0, 
              base_level_stop = 0, 
              cmp_it = {
                stop_pos = 0, 
                id = 0, 
                ch = 0, 
                rule_idx = 0, 
                lookback = 0, 
                nglyphs = 0, 
                reversed_p = false, 
                charpos = 0, 
                nchars = 0, 
                nbytes = 0, 
                from = 0, 
                to = 0, 
                width = 0
              }, 
              face_id = 0, 
              u = {
                image = {
                  object = 0, 
                  slice = {
                    x = 0, 
                    y = 0, 
                    width = 0, 
                    height = 0
                  }, 
                  image_id = 0
                }, 
                stretch = {
                  object = 0
                }, 
                xwidget = {
                  object = 0
                }
              }, 
              position = {
                charpos = 0, 
                bytepos = 0
              }, 
              current = {
                pos = {
                  charpos = 0, 
                  bytepos = 0
                }, 
                overlay_string_index = 0, 
                string_pos = {
                  charpos = 0, 
                  bytepos = 0
                }, 
                dpvec_index = 0
              }, 
              from_overlay = 0, 
              area = LEFT_MARGIN_AREA, 
              method = GET_FROM_BUFFER, 
              paragraph_embedding = NEUTRAL_DIR, 
              multibyte_p = false, 
              string_from_display_prop_p = false, 
              string_from_prefix_prop_p = false, 
              display_ellipsis_p = false, 
              avoid_cursor_p = false, 
              bidi_p = false, 
              from_disp_prop_p = false, 
              line_wrap = TRUNCATE, 
              voffset = 0, 
              space_width = 0, 
              font_height = 0
            }, {
              string = 0, 
              string_nchars = 0, 
              end_charpos = 0, 
              stop_charpos = 0, 
              prev_stop = 0, 
              base_level_stop = 0, 
              cmp_it = {
                stop_pos = 0, 
                id = 0, 
                ch = 0, 
                rule_idx = 0, 
                lookback = 0, 
                nglyphs = 0, 
                reversed_p = false, 
                charpos = 0, 
                nchars = 0, 
                nbytes = 0, 
                from = 0, 
                to = 0, 
                width = 0
              }, 
              face_id = 0, 
              u = {
                image = {
                  object = 0, 
                  slice = {
                    x = 0, 
                    y = 0, 
                    width = 0, 
                    height = 0
                  }, 
                  image_id = 0
                }, 
                stretch = {
                  object = 0
                }, 
                xwidget = {
                  object = 0
                }
              }, 
              position = {
                charpos = 0, 
                bytepos = 0
              }, 
              current = {
                pos = {
                  charpos = 0, 
                  bytepos = 0
                }, 
                overlay_string_index = 0, 
                string_pos = {
                  charpos = 0, 
                  bytepos = 0
                }, 
                dpvec_index = 0
              }, 
              from_overlay = 0, 
              area = LEFT_MARGIN_AREA, 
              method = GET_FROM_BUFFER, 
              paragraph_embedding = NEUTRAL_DIR, 
              multibyte_p = false, 
              string_from_display_prop_p = false, 
              string_from_prefix_prop_p = false, 
              display_ellipsis_p = false, 
              avoid_cursor_p = false, 
              bidi_p = false, 
              from_disp_prop_p = false, 
              line_wrap = TRUNCATE, 
              voffset = 0, 
              space_width = 0, 
              font_height = 0
            }, {
              string = 0, 
              string_nchars = 0, 
              end_charpos = 0, 
              stop_charpos = 0, 
              prev_stop = 0, 
              base_level_stop = 0, 
              cmp_it = {
                stop_pos = 0, 
                id = 0, 
                ch = 0, 
                rule_idx = 0, 
                lookback = 0, 
                nglyphs = 0, 
                reversed_p = false, 
                charpos = 0, 
                nchars = 0, 
                nbytes = 0, 
                from = 0, 
                to = 0, 
                width = 0
              }, 
              face_id = 0, 
              u = {
                image = {
                  object = 0, 
                  slice = {
                    x = 0, 
                    y = 0, 
                    width = 0, 
                    height = 0
                  }, 
                  image_id = 0
                }, 
                stretch = {
                  object = 0
                }, 
                xwidget = {
                  object = 0
                }
              }, 
              position = {
                charpos = 0, 
                bytepos = 0
              }, 
              current = {
                pos = {
                  charpos = 0, 
                  bytepos = 0
                }, 
                overlay_string_index = 0, 
                string_pos = {
                  charpos = 0, 
                  bytepos = 0
                }, 
                dpvec_index = 0
              }, 
              from_overlay = 0, 
              area = LEFT_MARGIN_AREA, 
              method = GET_FROM_BUFFER, 
              paragraph_embedding = NEUTRAL_DIR, 
              multibyte_p = false, 
              string_from_display_prop_p = false, 
              string_from_prefix_prop_p = false, 
              display_ellipsis_p = false, 
              avoid_cursor_p = false, 
              bidi_p = false, 
              from_disp_prop_p = false, 
              line_wrap = TRUNCATE, 
              voffset = 0, 
              space_width = 0, 
              font_height = 0
            }}, 
          sp = 0, 
          selective = 0, 
          what = IT_EOB, 
          face_id = 0, 
          selective_display_ellipsis_p = true, 
          ctl_arrow_p = true, 
          face_box_p = false, 
          start_of_box_run_p = false, 
          end_of_box_run_p = false, 
          overlay_strings_at_end_processed_p = true, 
          ignore_overlay_strings_at_pos_p = false, 
          glyph_not_available_p = false, 
          starts_in_middle_of_char_p = false, 
          face_before_selective_p = false, 
          constrain_row_ascent_descent_p = false, 
          line_wrap = WINDOW_WRAP, 
          base_face_id = 0, 
          c = 32, 
          len = 1, 
          cmp_it = {
            stop_pos = 391171, 
            id = -1, 
            ch = -2, 
            rule_idx = 0, 
            lookback = 0, 
            nglyphs = 0, 
            reversed_p = false, 
            charpos = 0, 
            nchars = 0, 
            nbytes = 0, 
            from = 0, 
            to = 0, 
            width = 0
          }, 
          char_to_display = 32, 
          glyphless_method = GLYPHLESS_DISPLAY_THIN_SPACE, 
          image_id = 0, 
          xwidget = 0x0, 
          slice = {
            x = 0, 
            y = 0, 
            width = 0, 
            height = 0
          }, 
          space_width = 0, 
          voffset = 0, 
          tab_width = 4, 
          font_height = 0, 
          object = 58622773, 
          position = {
            charpos = 391173, 
            bytepos = 391181
          }, 
          truncation_pixel_width = 0, 
          continuation_pixel_width = 6, 
          first_visible_x = 0, 
          last_visible_x = 480, 
          last_visible_y = 663, 
          extra_line_spacing = 1, 
          max_extra_line_spacing = 1, 
          override_ascent = -1, 
          override_descent = 0, 
          override_boff = 0, 
          glyph_row = 0x3b39c30, 
          area = TEXT_AREA, 
          nglyphs = 1, 
          pixel_width = 6, 
          ascent = 11, 
          descent = 3, 
          max_ascent = 11, 
          max_descent = 3, 
          phys_ascent = 0, 
          phys_descent = 0, 
          max_phys_ascent = 11, 
          max_phys_descent = 2, 
          current_x = 12, 
          continuation_lines_width = 0, 
          eol_pos = {
            charpos = 0, 
            bytepos = 0
          }, 
          current_y = 644, 
          first_vpos = 0, 
          vpos = 46, 
          hpos = 2, 
          left_user_fringe_bitmap = 0, 
          right_user_fringe_bitmap = 0, 
          left_user_fringe_face_id = 0, 
          right_user_fringe_face_id = 0, 
          bidi_p = true, 
          bidi_it = {
            bytepos = 391181, 
            charpos = 391173, 
            ch = -1, 
            nchars = 1, 
            ch_len = 1, 
            type = NEUTRAL_B, 
            type_after_wn = NEUTRAL_B, 
            orig_type = NEUTRAL_B, 
            resolved_level = 0 '\000', 
            isolate_level = 0 '\000', 
            invalid_levels = 0, 
            invalid_isolates = 0, 
            prev = {
              charpos = 391172, 
              type = UNKNOWN_BT, 
              orig_type = NEUTRAL_WS
            }, 
            last_strong = {
              charpos = 391168, 
              type = UNKNOWN_BT, 
              orig_type = UNKNOWN_BT
            }, 
            next_for_neutral = {
              charpos = 390500, 
              type = UNKNOWN_BT, 
              orig_type = UNKNOWN_BT
            }, 
            prev_for_neutral = {
              charpos = 391173, 
              type = STRONG_L, 
              orig_type = NEUTRAL_WS
            }, 
            next_for_ws = {
              charpos = -1, 
              type = UNKNOWN_BT, 
              orig_type = UNKNOWN_BT
            }, 
            bracket_pairing_pos = -1, 
            bracket_enclosed_type = UNKNOWN_BT, 
            next_en_pos = 0, 
            next_en_type = UNKNOWN_BT, 
            sos = L2R, 
            scan_dir = 1, 
            disp_pos = 391173, 
            disp_prop = 0, 
            stack_idx = 0, 
            level_stack = {{
                next_for_neutral_pos = 0, 
                next_for_neutral_type = 0, 
                last_strong_type = 0, 
                prev_for_neutral_type = 0, 
                level = 0 '\000', 
                flags = 0 '\000'
              } <repeats 128 times>}, 
            string = {
              lstring = 0, 
              s = 0x0, 
              schars = 0, 
              bufpos = 0, 
              from_disp_str = false, 
              unibyte = false
            }, 
            w = 0x37e08b0, 
            paragraph_dir = L2R, 
            separator_limit = -1, 
            first_elt = false, 
            new_paragraph = false, 
            frame_window_p = true
          }, 
          paragraph_embedding = NEUTRAL_DIR
        }
        temp_scroll_step = true
        rc = 0
        last_line_misfit = false
        itdata = 0x7fff02b4fe10
#39 0x0000000000467a1e in redisplay_window_1 (window=window@entry=58591413) at xdisp.c:14454
No locals.
#40 0x000000000056260c in internal_condition_case_1 (bfun=0x4679f0 <redisplay_window_1>, arg=58591413, handlers=<optimized out>, hfun=0x42cf60 <redisplay_window_error>) at eval.c:1333
        val = 333
        c = <optimized out>
#41 0x0000000000456ad0 in redisplay_internal () at xdisp.c:14079
        match_p = 176
#42 0x00000000004fa2b3 in read_char (commandflag=86946816, commandflag@entry=1, map=86617088, map@entry=86601331, prev_event=334, used_mouse_menu=0x0, used_mouse_menu@entry=0x7fff02b53dcb, 
    end_time=0x143ba01, end_time@entry=0x0) at keyboard.c:2477
        local_getcjmp = {{
            __jmpbuf = {58622773, 1564694, 29472, 1564690, 391168, 5988911, 391172, 66918760228998144}, 
            __mask_was_saved = 45431872, 
            __saved_mask = {
              __val = {1564694, 140733238819904, 29472, 391181, 18446744073709551615, 58622773, 5597497, 3, 401584, 58622768, 3743, 12620597, 391173, 1564694, 58622773, 0}
            }
          }}
        save_jump = {{
            __jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, 
            __mask_was_saved = 0, 
            __saved_mask = {
              __val = {0 <repeats 16 times>}
            }
          }}
        save = 13951632
        previous_echo_area_message = 0
        also_record = 0
        reread = false
        recorded = false
        polling_stopped_here = false
#43 0x00000000004fca76 in read_key_sequence (keybuf=keybuf@entry=0x7fff02b53ea0, prompt=prompt@entry=0, dont_downcase_last=dont_downcase_last@entry=false, 
    can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false, bufsize=30) at keyboard.c:9063
        interrupted_kboard = 0xd4e290
        interrupted_frame = 0x1224650
        key = <optimized out>
        used_mouse_menu = false
        echo_local_start = 0
        last_real_key_start = <optimized out>
        keys_local_start = <optimized out>
        new_binding = <optimized out>
        t = <optimized out>
        echo_start = 0
        keys_start = 0
        current_binding = 86601331
        first_event = 0
        first_unbound = 31
        mock_input = 0
        fkey = {
          parent = 17130995, 
          map = 17130995, 
          start = 0, 
          end = 0
        }
        keytran = {
          parent = 12570179, 
          map = 12570179, 
          start = 0, 
          end = 0
        }
        indec = {
          parent = 17131123, 
          map = 17131123, 
          start = 0, 
          end = 0
        }
        shift_translated = false
        delayed_switch_frame = 0
        original_uppercase = 0
        original_uppercase_position = -1
        dummyflag = false
        starting_buffer = 0x37e8330
        fake_prefixed_keys = 0
#44 0x00000000004fe6b6 in command_loop_1 () at keyboard.c:1365
        cmd = <optimized out>
        keybuf = {54, 78, 202, -6202091921070732288, 2822930839, -6202091921070732288, 9955464, 5377136, 73708083, 140733238820720, 73708083, 140733238821408, 0, 5652260, 317296, 73708083, 
          8756772, 5377136, 12340336, -6202091921070732288, 73708083, 5197970, 140733238820720, 0, 0, 5198303, 140733238821376, 5579137, 28416, 96}
        i = <optimized out>
        prev_modiff = 46990
        prev_buffer = 0x37e8330
#45 0x0000000000562686 in internal_condition_case (bfun=bfun@entry=0x4fe4b0 <command_loop_1>, handlers=handlers@entry=19056, hfun=hfun@entry=0x4f50c0 <cmd_error>) at eval.c:1309
        val = 333
        c = <optimized out>
#46 0x00000000004f06ec in command_loop_2 (ignore=ignore@entry=0) at keyboard.c:1107
        val = 333
#47 0x00000000005626eb in internal_catch (tag=tag@entry=45840, func=func@entry=0x4f06d0 <command_loop_2>, arg=arg@entry=0) at eval.c:1074
        val = 333
        c = <optimized out>
#48 0x00000000004f06a9 in command_loop () at keyboard.c:1086
No locals.
#49 0x00000000004f4cd7 in recursive_edit_1 () at keyboard.c:692
        val = <optimized out>
#50 0x00000000004f4ff0 in Frecursive_edit () at keyboard.c:763
        buffer = <optimized out>
#51 0x0000000000418dce in main (argc=1, argv=0x7fff02b54228) at emacs.c:1626
        dummy = 140069625578752
        stack_bottom_variable = 2 '\002'
        skip_args = 0
        rlim = {
          rlim_cur = 8720000, 
          rlim_max = 18446744073709551615
        }
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x0

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

 > 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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 850 bytes --]

>>    gdk_frame_clock_paint_idle
>>    → gtk_container_idle_sizer
>>    → gtk_distribute_natural_allocation
>
> Why doesn't this process kick in after I shrink the frame width
> manually such that the menu bar is cropped?  Something in the course

It does for me. If I try to shrink the frame manually it either
pops back immediately or after a brief pause (occasionally
a long pause, but it usually "wakes up" when I interact with the UI).

>> Worst case scenario: If I grab the scrolled window class and mutilate it
>
> Above I meant using the gtk fixed window class for the container, not
> the scrolled window one.

Oh, sure - I wasn't clear - I tried adding a gtk fixed and it behaves
for our purposes the same way as an hbox - it honours resize requests,
despite its name. The fixed appears to refer to layout (positioning)
only, not size.

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

 > 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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

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.

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

 > 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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 535 bytes --]

Hi - have been busy for a while but finally put this together.

The attached patch series:

  - Lets the user control menubar scrolling via a frame parameter.
  - Handles initial-frame-alist
  - Handles default-frame-alist
  - Handles the modify-frame-parameter path (this is secretly how initial
    frames work).
  - Documents the new frame parameter.

Patches prepared on top of the emacs-26 branch but should apply to master
too.

Let me know if the series needs any revision (I have already done the 
copyright-assignment dance).

[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 4396 bytes --]

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

 > 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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 365 bytes --]

> Please prepare patches that apply on master so people who use master
> only can test them.

Patchset attached.

Rebased on:

   5bd8cfc14d4b0c78c07e65a583f42a10c4cbc06d
   Fix mishandling of symbols that look like numbers

Built and briefly tested locally.

I still haven't been able to reproduced the missing menu bar symptom
you described, with or without -q.


[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 4412 bytes --]

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

 > 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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

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

...

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1029 bytes --]

GTK 3.16 and later:

The menu bar is always in a scrollwed window . In the default mode,
the menu bar is truncated when it tries to grow wider than the frame.
CSS is used to strip away the excess space this introduces.

In 'always or 'automatic mode, the CSS is relaxed slightly to work
around a GTK focus glitch, but otherwise the widget setup is identical.
The menubar will have a scrollbar either always, or when it tries to
grow too wide.

Before GTK 3.16:

When in 'always or 'automatic mode, the menu bar will be in a scrolled
window. The extra space cannot be properly ameliorated with CSS
styling as this does not seem to work well. In the default mode,
the scrolled window is not present - the menu bar is dynamically
re-parented between the scrolled window (which is created on demand)
and the emacs pane (vbox widget) when the menu bar scrolling mode
is changed.

At these GTK versions truncation does not work, so the menu bar
frame size jitter big persists in the default mode.

[ Tested on gtk 3.22.11 and 3.4.2 ]


[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 7740 bytes --]

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

 > 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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

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)

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

 > 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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

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_).

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

 > 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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 89 bytes --]

New patch series - I think this has all the features and functionality
discussed so far.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: TEXT/x-diff; name=0001-GTK3-menu-bars-force-frame-resizing-Bug-22000.patch, Size: 16011 bytes --]

From c9e24d6bf4d3d5baae9bb4dade97cfcb8a5ecafc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vivek=20Das=C2=A0Mohapatra?= <vivek@collabora.com>
Date: Sun, 15 Jul 2018 18:59:59 +0100
Subject: [PATCH 1/3] GTK3 menu bars force frame resizing (Bug#22000)

Menu bars force the frame they are in to resize when the menu bar
width exceeds the frame width, both at the point the menu bar grows
past the frame width and whenever the gtk idle resize callback is
triggered.

The effect is that the user's frame width is effectively ignored, and
emacs will semi-predictably resize itself to accommodate the menu bar.

This effect can be suppressed by wrapping the menu bar in a scrollable
window.

This behaviour is controlled by the `menu-bar-scrollbar' parameter
which may have a value of 'automatic, 'always, 'forced-resize or
anything else (equivalent to nil).

Limitations in earlier versions of GTK mean that there are
some version-dependent differences in behaviour.

GTK 3.16 and later:

The menu bar is always in a scrolled window . In the default mode
the menu bar is truncated when it tries to grow wider than the frame.
CSS is used to strip away the excess space this introduces.

In 'always or 'automatic mode, the CSS is relaxed slightly to work
around a GTK focus glitch, but otherwise the widget setup is identical.
The menubar will have a scrollbar either always, or when it tries to
grow too wide.

In 'forced-resize mode the frame-size-jitter behaviour described in
bug #22000 is preserved.

Before GTK 3.16:

When in 'always or 'automatic mode, the menu bar will be in a scrolled
window. The extra space cannot be properly ameliorated with CSS
styling as this does not seem to work well.

In the default mode, the scrolled window is not present - the menu bar
is dynamically re-parented between the scrolled window (which is
created on demand) and the emacs pane (vbox widget) when the menu bar
scrolling mode is changed.

In these versions of GTK the menu-bar truncation behaviour is not
easily achievable, so the default mode is identical to 'forced-resize
mode.
---
 src/frame.c   |   7 ++
 src/gtkutil.c | 203 +++++++++++++++++++++++++++++++++++++++++++++++++++++++---
 src/gtkutil.h |   3 +
 src/xfns.c    |  12 +++-
 src/xterm.h   |   4 ++
 5 files changed, 220 insertions(+), 9 deletions(-)

diff --git a/src/frame.c b/src/frame.c
index 0a6ca26f5d..e4e430de8f 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -3550,6 +3550,7 @@ static const struct frame_parm_table frame_parms[] =
   {"right-divider-width",	SYMBOL_INDEX (Qright_divider_width)},
   {"bottom-divider-width",	SYMBOL_INDEX (Qbottom_divider_width)},
   {"menu-bar-lines",		SYMBOL_INDEX (Qmenu_bar_lines)},
+  {"menu-bar-scrollbar",	SYMBOL_INDEX (Qmenu_bar_scrollbar)},
   {"mouse-color",		SYMBOL_INDEX (Qmouse_color)},
   {"name",			SYMBOL_INDEX (Qname)},
   {"scroll-bar-width",		SYMBOL_INDEX (Qscroll_bar_width)},
@@ -5660,6 +5661,11 @@ syms_of_frame (void)
   DEFSYM (Qx_resource_name, "x-resource-name");
   DEFSYM (Qx_frame_parameter, "x-frame-parameter");
 
+  /* Values for menu-bar-scrollbar frame parameter (GTK only) */
+  DEFSYM (Qautomatic, "automatic");
+  DEFSYM (Qalways, "always");
+  DEFSYM (Qforced_resize, "forced-resize");
+
   DEFSYM (Qworkarea, "workarea");
   DEFSYM (Qmm_size, "mm-size");
   DEFSYM (Qframes, "frames");
@@ -5675,6 +5681,7 @@ syms_of_frame (void)
   DEFSYM (Qtitle_bar_size, "title-bar-size");
   DEFSYM (Qmenu_bar_external, "menu-bar-external");
   DEFSYM (Qmenu_bar_size, "menu-bar-size");
+  DEFSYM (Qmenu_bar_scrollbar, "menu-bar-scrollbar");
   DEFSYM (Qtool_bar_external, "tool-bar-external");
   DEFSYM (Qtool_bar_size, "tool-bar-size");
   /* The following are used for frame_size_history.  */
diff --git a/src/gtkutil.c b/src/gtkutil.c
index 83b306a730..c4637e0cba 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -1136,6 +1136,10 @@ delete_cb (GtkWidget *widget,
   return TRUE;
 }
 
+#define MENUBAR_STYLESHEET \
+  ".mbtrunc  * { border-width: 1px; margin-top: -2px; margin-bottom: -2px; }\n" \
+  ".mbscroll * { border-width: 1px; margin-top: -1px; margin-bottom: 0px; }\n"
+
 /* Create and set up the GTK widgets for frame F.
    Return true if creation succeeded.  */
 
@@ -1147,6 +1151,9 @@ xg_create_frame_widgets (struct frame *f)
   GtkWidget *wfixed;
 #ifndef HAVE_GTK3
   GtkRcStyle *style;
+#else
+  GtkCssProvider *css;
+  GdkScreen *screen;
 #endif
   char *title = 0;
 
@@ -1213,6 +1220,17 @@ xg_create_frame_widgets (struct frame *f)
       store_frame_param (f, Qundecorated, Qt);
     }
 
+  /* Add a CSS provider for the frame which will be used for dynamic styling
+     when we change widget behaviour (eg menubar scrollbars).  */
+  css = gtk_css_provider_new ();
+  screen = gtk_widget_get_screen (wtop);
+  /* This should probably be moved ino the filesystem.  */
+  gtk_css_provider_load_from_data (css, MENUBAR_STYLESHEET, -1, NULL);
+  gtk_style_context_add_provider_for_screen (screen,
+                                             GTK_STYLE_PROVIDER (css),
+                                             GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
+  g_object_unref (css);
+
   FRAME_GTK_OUTER_WIDGET (f) = wtop;
   FRAME_GTK_WIDGET (f) = wfixed;
   f->output_data.x->vbox_widget = wvbox;
@@ -3434,7 +3452,11 @@ menubar_map_cb (GtkWidget *w, gpointer user_data)
 {
   GtkRequisition req;
   struct frame *f = user_data;
-  gtk_widget_get_preferred_size (w, NULL, &req);
+  struct x_output *x = f->output_data.x;
+
+  /* Use the menubar viewport for size if there is one: */
+  gtk_widget_get_preferred_size (x->menubar_visible_widget ?: w, NULL, &req);
+
   if (FRAME_MENUBAR_HEIGHT (f) != req.height)
     {
       FRAME_MENUBAR_HEIGHT (f) = req.height;
@@ -3442,6 +3464,150 @@ menubar_map_cb (GtkWidget *w, gpointer user_data)
     }
 }
 
+/* Remove a gtk widget from any parent it may belong to.
+   Ensures that this does not change target's ref count.  */
+static void
+orphan_widget (GtkWidget *w)
+{
+  GtkWidget *parent = gtk_widget_get_parent (w);
+
+  if (parent && GTK_IS_CONTAINER (parent))
+    {
+      g_object_ref (w);
+      gtk_container_remove (GTK_CONTAINER (parent), w);
+
+#if !GTK_CHECK_VERSION(3, 8, 0)
+      /* gtk 3.8 and earlier: viewport must be managed manually
+         but we don't need to save it, unlike the scrolled window
+         or the menubar.  */
+      if (GTK_IS_VIEWPORT (parent))
+        {
+          GtkWidget *grandparent = gtk_widget_get_parent (parent);
+
+          if (parent && GTK_IS_CONTAINER (grandparent))
+            gtk_container_remove (GTK_CONTAINER (grandparent), parent);
+        }
+#endif
+      return;
+    }
+}
+
+/* As per orphan_widget but we also want to get rid of it and clean up.  */
+static void
+discard_widget (GtkWidget *w)
+{
+  orphan_widget  (w);
+  if (g_object_is_floating (w))
+    g_object_ref_sink (w);
+  g_object_unref (w);
+}
+
+/* Sets up the menubar style for scrolling/non-scrolling modes.
+   Reparents the menubar directly into the vbox for non-scrolling
+   mode and adds a scrolledwindow+viewport for scrolling modes.  */
+static void
+menubar_scrollbox (struct frame *f, int scroll)
+{
+  struct x_output *x = f->output_data.x;
+
+  if (scroll)
+    {
+      if (x->menubar_visible_widget == x->menubar_viewport)
+        return;
+
+      x->menubar_visible_widget = x->menubar_viewport;
+      orphan_widget (x->menubar_widget);
+
+#if GTK_CHECK_VERSION (3, 8, 0)
+      gtk_container_add (GTK_CONTAINER (x->menubar_viewport), x->menubar_widget);
+#else
+      gtk_scrolled_window_add_with_viewport (GTK_SCROLLED_WINDOW (x->menubar_viewport), x->menubar_widget);
+#endif
+    }
+  else
+    {
+      if (x->menubar_visible_widget == x->menubar_widget)
+        return;
+
+      x->menubar_visible_widget = x->menubar_widget;
+      orphan_widget (x->menubar_widget);
+      orphan_widget (x->menubar_viewport);
+    }
+
+  gtk_box_pack_start (GTK_BOX (x->vbox_widget),
+                      GTK_WIDGET (x->menubar_visible_widget), FALSE, FALSE, 0);
+  gtk_box_reorder_child (GTK_BOX (x->vbox_widget),
+                         GTK_WIDGET (x->menubar_visible_widget), 0);
+  gtk_widget_show_all (x->menubar_visible_widget);
+}
+
+#if GTK_CHECK_VERSION (3, 16, 0)
+#define MENUBAR_SCROLLBAR_DEFAULT_POLICY GTK_POLICY_EXTERNAL
+#else
+#define MENUBAR_SCROLLBAR_DEFAULT_POLICY GTK_POLICY_NEVER
+#endif
+
+/* Apply the scrollbar mode and related style settings.
+   This also inserts or removes the intervening viewport as necessary
+   and maps any widgets that need mapping. Note that after gtk 3.16
+   we don't need (or want) to remove the scrolledwindow or viewport,
+   it suffices to change their style.  */
+void
+xg_update_frame_menubar_scrollbar_mode (struct frame *f, Lisp_Object mode)
+{
+  GtkStyleContext *style;
+  struct x_output *x = f->output_data.x;
+  GtkScrolledWindow *sw;
+  GtkPolicyType scroll_policy = MENUBAR_SCROLLBAR_DEFAULT_POLICY;
+
+  if (!x->menubar_viewport)
+    return;
+
+  if (EQ (mode, Qautomatic))
+    scroll_policy = GTK_POLICY_AUTOMATIC;
+  else if (EQ (mode, Qalways))
+    scroll_policy = GTK_POLICY_ALWAYS;
+  else if (EQ (mode, Qforced_resize))
+    scroll_policy = GTK_POLICY_NEVER;
+
+  sw = GTK_SCROLLED_WINDOW (x->menubar_viewport);
+  style = gtk_widget_get_style_context (x->menubar_viewport);
+
+#if GTK_CHECK_VERSION(3, 16, 0)
+  /* Always want the scrollable container for capable-enough GTK versions */
+  menubar_scrollbox (f, 1);
+
+  switch (scroll_policy)
+    {
+    case GTK_POLICY_AUTOMATIC:
+    case GTK_POLICY_ALWAYS:
+      gtk_style_context_add_class (style, "mbscroll");
+      gtk_style_context_remove_class (style, "mbtrunc");
+      break;
+    default:
+      gtk_style_context_remove_class (style, "mbscroll");
+      gtk_style_context_add_class (style, "mbtrunc");
+    }
+#else
+  /* In older GTK versions we need to swap out the scrollable container
+     instead since we can't get truncating behaviour and CSS styling is
+     not well supported. */
+  switch (scroll_policy)
+    {
+    case GTK_POLICY_AUTOMATIC:
+    case GTK_POLICY_ALWAYS:
+      menubar_scrollbox (f, 1);
+      gtk_style_context_remove_class (style, "mbtrunc");
+      break;
+    default:
+      menubar_scrollbox (f, 0);
+      gtk_style_context_add_class (style, "mbtrunc");
+    }
+#endif
+
+  gtk_scrolled_window_set_policy (sw, scroll_policy, GTK_POLICY_AUTOMATIC);
+}
+
 /* Recompute all the widgets of frame F, when the menu bar has been
    changed.  */
 
@@ -3450,6 +3616,7 @@ xg_update_frame_menubar (struct frame *f)
 {
   struct x_output *x = f->output_data.x;
   GtkRequisition req;
+  Lisp_Object menuscroll;
 
   if (!x->menubar_widget || gtk_widget_get_mapped (x->menubar_widget))
     return;
@@ -3459,13 +3626,29 @@ xg_update_frame_menubar (struct frame *f)
 
   block_input ();
 
-  gtk_box_pack_start (GTK_BOX (x->vbox_widget), x->menubar_widget,
-                      FALSE, FALSE, 0);
-  gtk_box_reorder_child (GTK_BOX (x->vbox_widget), x->menubar_widget, 0);
+  menuscroll = get_frame_param (f, Qmenu_bar_scrollbar);
+
+  /* Put the menu bar inside a scrolled window so that adding items
+     to the menu bar (such as when entering dired mode or activating
+     a minor more) does not trigger a frame resize:*/
+  x->menubar_viewport = gtk_scrolled_window_new(NULL, NULL);
+
+  /* Leave the keyboard focus where it is when clicking the scrollwindow: */
+#if GTK_CHECK_VERSION (3, 20, 0)
+  gtk_widget_set_focus_on_click (x->menubar_viewport, FALSE);
+#endif
+
+#if GTK_CHECK_VERSION (3, 16, 0)
+  /* If we don't set this then the scrollable keeps focus when the user
+     interacts with the scrollbar, at least until the menubar is clicked.
+     Overlay scrolling is more compact but until the focus problem is fixed
+     it's not livable with. */
+  gtk_scrolled_window_set_overlay_scrolling (GTK_SCROLLED_WINDOW (x->menubar_viewport), FALSE);
+#endif
 
   g_signal_connect (x->menubar_widget, "map", G_CALLBACK (menubar_map_cb), f);
-  gtk_widget_show_all (x->menubar_widget);
-  gtk_widget_get_preferred_size (x->menubar_widget, NULL, &req);
+  xg_update_frame_menubar_scrollbar_mode (f, menuscroll);
+  gtk_widget_get_preferred_size (x->menubar_visible_widget, NULL, &req);
 
   if (FRAME_MENUBAR_HEIGHT (f) != req.height)
     {
@@ -3487,10 +3670,14 @@ free_frame_menubar (struct frame *f)
     {
       block_input ();
 
-      gtk_container_remove (GTK_CONTAINER (x->vbox_widget), x->menubar_widget);
+      discard_widget (x->menubar_widget);
+      discard_widget (x->menubar_viewport);
+
        /* The menubar and its children shall be deleted when removed from
           the container.  */
-      x->menubar_widget = 0;
+      x->menubar_visible_widget = NULL;
+      x->menubar_viewport = NULL;
+      x->menubar_widget = NULL;
       FRAME_MENUBAR_HEIGHT (f) = 0;
       adjust_frame_size (f, -1, -1, 2, 0, Qmenu_bar_lines);
       unblock_input ();
diff --git a/src/gtkutil.h b/src/gtkutil.h
index 7dcd549f5c..96220f27c8 100644
--- a/src/gtkutil.h
+++ b/src/gtkutil.h
@@ -103,6 +103,9 @@ extern void xg_modify_menubar_widgets (GtkWidget *menubar,
                                        GCallback deactivate_cb,
                                        GCallback highlight_cb);
 
+extern void xg_update_frame_menubar_scrollbar_mode (struct frame *f,
+                                                    Lisp_Object mode);
+
 extern void xg_update_frame_menubar (struct frame *f);
 
 extern bool xg_event_is_for_menubar (struct frame *, const XEvent *);
diff --git a/src/xfns.c b/src/xfns.c
index 3da853ede8..9503ae1e1d 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -1601,6 +1601,13 @@ x_set_menu_bar_lines (struct frame *f, Lisp_Object value, Lisp_Object oldval)
   adjust_frame_glyphs (f);
 }
 
+static void
+x_set_menu_bar_scrollbar (struct frame *f, Lisp_Object value, Lisp_Object oldval)
+{
+#ifdef USE_GTK /* menubar resize/scrolling only happens under GTK.  */
+  xg_update_frame_menubar_scrollbar_mode (f, value);
+#endif
+}
 
 /* Set the number of lines used for the tool bar of frame F to VALUE.
    VALUE not an integer, or < 0 means set the lines to zero.  OLDVAL
@@ -3888,7 +3895,9 @@ This function is an internal primitive--use `make-frame' instead.  */)
 		       NILP (Vtool_bar_mode)
 		       ? make_number (0) : make_number (1),
 		       NULL, NULL, RES_TYPE_NUMBER);
-
+  /* How scrolling is handled for oversized (too wide) menu bars.  */
+  x_default_parameter (f, parms, Qmenu_bar_scrollbar, Qnil,
+                       NULL, NULL, RES_TYPE_SYMBOL);
   x_default_parameter (f, parms, Qbuffer_predicate, Qnil,
 		       "bufferPredicate", "BufferPredicate",
 		       RES_TYPE_SYMBOL);
@@ -7536,6 +7545,7 @@ frame_parm_handler x_frame_parm_handlers[] =
   x_set_right_divider_width,
   x_set_bottom_divider_width,
   x_set_menu_bar_lines,
+  x_set_menu_bar_scrollbar,
   x_set_mouse_color,
   x_explicitly_set_name,
   x_set_scroll_bar_width,
diff --git a/src/xterm.h b/src/xterm.h
index f73dd0e25a..ac5f7f08da 100644
--- a/src/xterm.h
+++ b/src/xterm.h
@@ -581,7 +581,11 @@ struct x_output
   /* The widget used for laying out widgets horizontally.  */
   GtkWidget *hbox_widget;
   /* The menubar in this frame.  */
+  GtkWidget *menubar_viewport;
   GtkWidget *menubar_widget;
+  /* If the viewport is in usem this will be the viewport, otherwise it
+     will be the menubar_widget. Used to get height calculations right. */
+  GtkWidget *menubar_visible_widget;
   /* The tool bar in this frame  */
   GtkWidget *toolbar_widget;
   /* True if tool bar is packed into the hbox widget (i.e. vertical).  */
-- 
2.11.0


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: Type: TEXT/x-diff; name=0002-Document-the-new-menu-bar-scrollbar-frame-parameter.patch, Size: 2022 bytes --]

From 489a38cceda02e62dc50367347930713f4454f95 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vivek=20Das=C2=A0Mohapatra?= <vivek@collabora.com>
Date: Thu, 11 Oct 2018 13:48:47 +0100
Subject: [PATCH 2/3] Document the new menu-bar-scrollbar frame parameter

---
 doc/lispref/frames.texi | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/doc/lispref/frames.texi b/doc/lispref/frames.texi
index 2f9bb39886..601749d97e 100644
--- a/doc/lispref/frames.texi
+++ b/doc/lispref/frames.texi
@@ -601,6 +601,10 @@ Frame Layout
 frame unchanged, so the native height of the frame (see below) will
 change instead.
 
+If the menu bar is drawn by GTK then its behavior when it would grow
+wider than the root frame is controlled by the @code{menu-bar-scrollbar}
+parameter (@pxref{Layout Parameters}).
+
 @item Tool Bar
 @cindex internal tool bar
 @cindex external tool bar
@@ -1814,6 +1818,23 @@ Layout Parameters
 (@pxref{Frame Geometry}) allows to derive whether the menu bar actually
 occupies one or more lines.
 
+@vindex menu-bar-scrollbar@r{, a frame parameter}
+@item menu-bar-scrollbar
+The behavior of GTK menu bars when they would otherwise grow wider than
+the frame.  Valid values are:
+@itemize
+@item @code{always} - Scrollbar is present, menu bar scrolls when too wide.
+@item @code{automatic} - Scrollbar appears when menubar grows too wide.
+@item @code{forced-resize} - No scrollbar.  Growing menubar forces a frame resize.
+@item @code{nil} (or any other value)
+@itemize
+@item GTK >= 3.16 - No scrollbar.  Menu bar is truncated if it grows too wide.
+@item GTK < 3,16 - Same behavior as @code{forced-resize}.
+@end itemize
+@end itemize
+It is worth noting that for GTK before 3.16 the scrollbar adds a significant
+amount of vertical padding to the menubar: This appears to be unavoidable.
+
 @vindex tool-bar-lines@r{, a frame parameter}
 @item tool-bar-lines
 The number of lines to use for the tool bar (@pxref{Tool Bar}).  The
-- 
2.11.0


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: Type: TEXT/x-diff; name=0003-Hook-up-menu-bar-scrollbar-functionality-to-customiz.patch, Size: 8879 bytes --]

From d281f45206321ef7e41e73baa0edf67f0e7216be Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vivek=20Das=C2=A0Mohapatra?= <vivek@collabora.com>
Date: Thu, 18 Oct 2018 01:38:05 +0100
Subject: [PATCH 3/3] Hook up menu bar scrollbar functionality to customize &
 Options menu
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

menu-bar-scrollbar-mode custom variable updates default and
initial frame parameters.

menu-bar-scrollbar-mode command cycles the custom variable through
the available/supported values

Options ► Show Hide ► Menu Bar Scroll/Truncate menu connected to
the custom variable.
---
 lisp/menu-bar.el | 137 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 137 insertions(+)

diff --git a/lisp/menu-bar.el b/lisp/menu-bar.el
index e2ebd98119..e8b36851e2 100644
--- a/lisp/menu-bar.el
+++ b/lisp/menu-bar.el
@@ -673,6 +673,7 @@ menu-bar-options-save
 		   line-number-mode column-number-mode size-indication-mode
 		   cua-mode show-paren-mode transient-mark-mode
 		   blink-cursor-mode display-time-mode display-battery-mode
+                   menu-bar-scrollbar-mode
 		   ;; These are set by other functions that don't set
 		   ;; the customized state.  Having them here has the
 		   ;; side-effect that turning them off via X
@@ -1042,6 +1043,137 @@ menu-bar-showhide-tool-bar-menu-customize-enable-bottom
   (interactive)
   (menu-bar-set-tool-bar-position 'bottom))
 
+(defcustom menu-bar-scrollbar-mode nil
+      "Specify how GTK menu bars deal with the frame being too narrow to hold them.\n
+Valid values are:
+  `always'        - the menu bar always has a scrollbar
+  `automatic'     - a scrollbar is added when required
+  `forced-resize' - no scrollbar, the frame is forced to resize to accommodate
+                    the menu bar.
+   nil (or any other value) - the menu bar is truncated\n
+Note that prior to GTK 3.16 truncation is not possible and the default
+is equivalent to 'forced-resize.\n
+Do not set this variable directly - use the customize interface to make sure
+that `default-frame-alist', `initial-frame-alist' and all existing frames
+remain in sync."
+      :version "26.1"
+      :type '(choice (const always)
+		     (const automaic)
+		     (const forced-resize)
+		     (const nil))
+      :group 'frames
+      :initialize 'custom-initialize-default
+      :set (lambda (sym val)
+             (setq val (if (memq val '(automatic always forced-resize)) val nil))
+             (set-default sym val)
+             (modify-all-frames-parameters
+	      (list (cons 'menu-bar-scrollbar val)))))
+
+(defun menu-bar-can-be-truncated ()
+  (let (version)
+    (when (boundp 'gtk-version-string)
+      (setq version (mapcar 'string-to-number (split-string gtk-version-string "\\.")))
+      (or (and (eq (car version) 3) (>= (cadr version) 16))
+          (>= (car version) 4)))))
+
+(defun menu-bar-scrollbar-next-mode (mode)
+  "Return the next menu-bar-scrollbar frame parameter value after MODE.
+Takes into account the abilities of the available GTK version."
+  (if (menu-bar-can-be-truncated)
+      (progn
+        (if (not (memq mode '(always automatic forced-resize nil))) (setq mode nil))
+        (cadr (memq mode '(nil automatic always forced-resize nil))))
+    (if (not (memq mode '(always automatic nil))) (setq mode nil))
+    (cadr (memq mode '(nil automatic always nil)))))
+
+(defun menu-bar-scrollbar-mode (&optional mode)
+  "Cycle through scroll/truncate/resize modes for GTK menu bars.\n
+If the optional parameter MODE is specified then apply that instead.
+The new mode is stored in the variable `menu-bar-scrollbar-mode' via
+the custom interface (but not automatically saved).\n
+Returns the new MODE.\n
+NOTE: pass 'default if you want to set the mode explicitly to nil.\n
+See `menu-bar-scrollbar' in Info node `(elisp)Layout Parameters' for details."
+  (interactive)
+  (if mode
+      ;; explicit mode passed, map any non-standard value back to nil
+      (setq mode (car (memq mode '(automatic always forced-resize))))
+    ;; no explicit mode: pick the new value based on our fixed progression:
+    (setq mode (menu-bar-scrollbar-next-mode
+                (or menu-bar-scrollbar-mode 'default))))
+  ;; set, apply but do not save the new value:
+  (customize-set-variable 'menu-bar-scrollbar-mode mode)
+  mode)
+
+(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-forced-resize ()
+  "Resize the frame to accommodate the menu bar."
+  (interactive)
+  (customize-set-variable 'menu-bar-scrollbar-mode 'forced-resize))
+(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-always ()
+  "Add a permanent scrollbar to the menu bar."
+  (interactive)
+  (customize-set-variable 'menu-bar-scrollbar-mode 'always))
+(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-automatic ()
+  "Add a scrollbar to the menu bar when it tries to grow past the frame edge.."
+  (interactive)
+  (customize-set-variable 'menu-bar-scrollbar-mode 'automatic))
+(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-nil ()
+  "Truncate the menu bar to fit the frame."
+  (interactive)
+  (customize-set-variable 'menu-bar-scrollbar-mode 'default))
+
+(defvar menu-bar-showhide-menu-bar-scrollbar-mode-menu
+  (let ((menu (make-sparse-keymap "Menu Bar Scroll/Truncate")))
+
+    (bindings--define-key menu [showhide-menu-bar-scrollbar-mode-forced-resize]
+      '(menu-item "Resize Frame"
+                  menu-bar-showhide-menu-bar-scrollbar-mode-customize-forced-resize
+                  :help "Resize the frame to accommodate the menu bar"
+                  :visible (display-graphic-p)
+                  :button
+                  (:radio . (if (menu-bar-can-be-truncated)
+                                (eq (frame-parameter
+                                     (menu-bar-frame-for-menubar)
+                                     'menu-bar-scrollbar)
+                                    'forced-resize)
+                              (not (memq (frame-parameter
+                                          (menu-bar-frame-for-menubar)
+                                          'menu-bar-scrollbar)
+                                         '(automatic always)))))))
+
+    (bindings--define-key menu [showhide-menu-bar-scrollbar-mode-always]
+      '(menu-item "Always Scroll"
+                  menu-bar-showhide-menu-bar-scrollbar-mode-customize-always
+                  :help "Always add a scroll bar to the menu bar"
+                  :visible (display-graphic-p)
+                  :button
+                  (:radio . (eq (frame-parameter (menu-bar-frame-for-menubar)
+                                                 'menu-bar-scrollbar)
+                                'always))))
+
+    (bindings--define-key menu [showhide-menu-bar-scrollbar-mode-automatic]
+      '(menu-item "Automatic"
+                  menu-bar-showhide-menu-bar-scrollbar-mode-customize-automatic
+                  :help "Display a scroll bar only when the menu is too wide"
+                  :visible (display-graphic-p)
+                  :button
+                  (:radio . (eq (frame-parameter (menu-bar-frame-for-menubar)
+                                                 'menu-bar-scrollbar)
+                                'automatic))))
+
+    (bindings--define-key menu [showhide-menu-bar-scrollbar-mode-truncate]
+      '(menu-item "Truncate"
+                  menu-bar-showhide-menu-bar-scrollbar-mode-customize-nil
+                  :help "Truncate the menubar to fit inside the frame"
+                  :visible (and (display-graphic-p)
+                                (menu-bar-can-be-truncated))
+                  :button
+                  (:radio . (not (memq
+                                  (frame-parameter (menu-bar-frame-for-menubar)
+                                                   'menu-bar-scrollbar)
+                                       '(automatic always forced-resize))))))
+    menu))
+
 (when (featurep 'move-toolbar)
   (defvar menu-bar-showhide-tool-bar-menu
     (let ((menu (make-sparse-keymap "Tool Bar")))
@@ -1225,6 +1357,11 @@ menu-bar-showhide-menu
                   :visible (and (display-graphic-p) (fboundp 'x-show-tip))
                   :button (:toggle . tooltip-mode)))
 
+    (bindings--define-key menu [showhide-menu-bar-scrollbar-menu]
+      `(menu-item "Menu Bar Scroll/Truncate"
+                  ,menu-bar-showhide-menu-bar-scrollbar-mode-menu
+                  :visible (display-graphic-p)))
+
     (bindings--define-key menu [menu-bar-mode]
       '(menu-item "Menu Bar" toggle-menu-bar-mode-from-frame
                   :help "Turn menu bar on/off"
-- 
2.11.0

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

 > 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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 63 bytes --]

featurep guards added, defcustom setting emacs version bumped.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: TEXT/x-diff; name=0001-GTK3-menu-bars-force-frame-resizing-Bug-22000.patch, Size: 16011 bytes --]

From c9e24d6bf4d3d5baae9bb4dade97cfcb8a5ecafc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vivek=20Das=C2=A0Mohapatra?= <vivek@collabora.com>
Date: Sun, 15 Jul 2018 18:59:59 +0100
Subject: [PATCH 1/3] GTK3 menu bars force frame resizing (Bug#22000)

Menu bars force the frame they are in to resize when the menu bar
width exceeds the frame width, both at the point the menu bar grows
past the frame width and whenever the gtk idle resize callback is
triggered.

The effect is that the user's frame width is effectively ignored, and
emacs will semi-predictably resize itself to accommodate the menu bar.

This effect can be suppressed by wrapping the menu bar in a scrollable
window.

This behaviour is controlled by the `menu-bar-scrollbar' parameter
which may have a value of 'automatic, 'always, 'forced-resize or
anything else (equivalent to nil).

Limitations in earlier versions of GTK mean that there are
some version-dependent differences in behaviour.

GTK 3.16 and later:

The menu bar is always in a scrolled window . In the default mode
the menu bar is truncated when it tries to grow wider than the frame.
CSS is used to strip away the excess space this introduces.

In 'always or 'automatic mode, the CSS is relaxed slightly to work
around a GTK focus glitch, but otherwise the widget setup is identical.
The menubar will have a scrollbar either always, or when it tries to
grow too wide.

In 'forced-resize mode the frame-size-jitter behaviour described in
bug #22000 is preserved.

Before GTK 3.16:

When in 'always or 'automatic mode, the menu bar will be in a scrolled
window. The extra space cannot be properly ameliorated with CSS
styling as this does not seem to work well.

In the default mode, the scrolled window is not present - the menu bar
is dynamically re-parented between the scrolled window (which is
created on demand) and the emacs pane (vbox widget) when the menu bar
scrolling mode is changed.

In these versions of GTK the menu-bar truncation behaviour is not
easily achievable, so the default mode is identical to 'forced-resize
mode.
---
 src/frame.c   |   7 ++
 src/gtkutil.c | 203 +++++++++++++++++++++++++++++++++++++++++++++++++++++++---
 src/gtkutil.h |   3 +
 src/xfns.c    |  12 +++-
 src/xterm.h   |   4 ++
 5 files changed, 220 insertions(+), 9 deletions(-)

diff --git a/src/frame.c b/src/frame.c
index 0a6ca26f5d..e4e430de8f 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -3550,6 +3550,7 @@ static const struct frame_parm_table frame_parms[] =
   {"right-divider-width",	SYMBOL_INDEX (Qright_divider_width)},
   {"bottom-divider-width",	SYMBOL_INDEX (Qbottom_divider_width)},
   {"menu-bar-lines",		SYMBOL_INDEX (Qmenu_bar_lines)},
+  {"menu-bar-scrollbar",	SYMBOL_INDEX (Qmenu_bar_scrollbar)},
   {"mouse-color",		SYMBOL_INDEX (Qmouse_color)},
   {"name",			SYMBOL_INDEX (Qname)},
   {"scroll-bar-width",		SYMBOL_INDEX (Qscroll_bar_width)},
@@ -5660,6 +5661,11 @@ syms_of_frame (void)
   DEFSYM (Qx_resource_name, "x-resource-name");
   DEFSYM (Qx_frame_parameter, "x-frame-parameter");
 
+  /* Values for menu-bar-scrollbar frame parameter (GTK only) */
+  DEFSYM (Qautomatic, "automatic");
+  DEFSYM (Qalways, "always");
+  DEFSYM (Qforced_resize, "forced-resize");
+
   DEFSYM (Qworkarea, "workarea");
   DEFSYM (Qmm_size, "mm-size");
   DEFSYM (Qframes, "frames");
@@ -5675,6 +5681,7 @@ syms_of_frame (void)
   DEFSYM (Qtitle_bar_size, "title-bar-size");
   DEFSYM (Qmenu_bar_external, "menu-bar-external");
   DEFSYM (Qmenu_bar_size, "menu-bar-size");
+  DEFSYM (Qmenu_bar_scrollbar, "menu-bar-scrollbar");
   DEFSYM (Qtool_bar_external, "tool-bar-external");
   DEFSYM (Qtool_bar_size, "tool-bar-size");
   /* The following are used for frame_size_history.  */
diff --git a/src/gtkutil.c b/src/gtkutil.c
index 83b306a730..c4637e0cba 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -1136,6 +1136,10 @@ delete_cb (GtkWidget *widget,
   return TRUE;
 }
 
+#define MENUBAR_STYLESHEET \
+  ".mbtrunc  * { border-width: 1px; margin-top: -2px; margin-bottom: -2px; }\n" \
+  ".mbscroll * { border-width: 1px; margin-top: -1px; margin-bottom: 0px; }\n"
+
 /* Create and set up the GTK widgets for frame F.
    Return true if creation succeeded.  */
 
@@ -1147,6 +1151,9 @@ xg_create_frame_widgets (struct frame *f)
   GtkWidget *wfixed;
 #ifndef HAVE_GTK3
   GtkRcStyle *style;
+#else
+  GtkCssProvider *css;
+  GdkScreen *screen;
 #endif
   char *title = 0;
 
@@ -1213,6 +1220,17 @@ xg_create_frame_widgets (struct frame *f)
       store_frame_param (f, Qundecorated, Qt);
     }
 
+  /* Add a CSS provider for the frame which will be used for dynamic styling
+     when we change widget behaviour (eg menubar scrollbars).  */
+  css = gtk_css_provider_new ();
+  screen = gtk_widget_get_screen (wtop);
+  /* This should probably be moved ino the filesystem.  */
+  gtk_css_provider_load_from_data (css, MENUBAR_STYLESHEET, -1, NULL);
+  gtk_style_context_add_provider_for_screen (screen,
+                                             GTK_STYLE_PROVIDER (css),
+                                             GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
+  g_object_unref (css);
+
   FRAME_GTK_OUTER_WIDGET (f) = wtop;
   FRAME_GTK_WIDGET (f) = wfixed;
   f->output_data.x->vbox_widget = wvbox;
@@ -3434,7 +3452,11 @@ menubar_map_cb (GtkWidget *w, gpointer user_data)
 {
   GtkRequisition req;
   struct frame *f = user_data;
-  gtk_widget_get_preferred_size (w, NULL, &req);
+  struct x_output *x = f->output_data.x;
+
+  /* Use the menubar viewport for size if there is one: */
+  gtk_widget_get_preferred_size (x->menubar_visible_widget ?: w, NULL, &req);
+
   if (FRAME_MENUBAR_HEIGHT (f) != req.height)
     {
       FRAME_MENUBAR_HEIGHT (f) = req.height;
@@ -3442,6 +3464,150 @@ menubar_map_cb (GtkWidget *w, gpointer user_data)
     }
 }
 
+/* Remove a gtk widget from any parent it may belong to.
+   Ensures that this does not change target's ref count.  */
+static void
+orphan_widget (GtkWidget *w)
+{
+  GtkWidget *parent = gtk_widget_get_parent (w);
+
+  if (parent && GTK_IS_CONTAINER (parent))
+    {
+      g_object_ref (w);
+      gtk_container_remove (GTK_CONTAINER (parent), w);
+
+#if !GTK_CHECK_VERSION(3, 8, 0)
+      /* gtk 3.8 and earlier: viewport must be managed manually
+         but we don't need to save it, unlike the scrolled window
+         or the menubar.  */
+      if (GTK_IS_VIEWPORT (parent))
+        {
+          GtkWidget *grandparent = gtk_widget_get_parent (parent);
+
+          if (parent && GTK_IS_CONTAINER (grandparent))
+            gtk_container_remove (GTK_CONTAINER (grandparent), parent);
+        }
+#endif
+      return;
+    }
+}
+
+/* As per orphan_widget but we also want to get rid of it and clean up.  */
+static void
+discard_widget (GtkWidget *w)
+{
+  orphan_widget  (w);
+  if (g_object_is_floating (w))
+    g_object_ref_sink (w);
+  g_object_unref (w);
+}
+
+/* Sets up the menubar style for scrolling/non-scrolling modes.
+   Reparents the menubar directly into the vbox for non-scrolling
+   mode and adds a scrolledwindow+viewport for scrolling modes.  */
+static void
+menubar_scrollbox (struct frame *f, int scroll)
+{
+  struct x_output *x = f->output_data.x;
+
+  if (scroll)
+    {
+      if (x->menubar_visible_widget == x->menubar_viewport)
+        return;
+
+      x->menubar_visible_widget = x->menubar_viewport;
+      orphan_widget (x->menubar_widget);
+
+#if GTK_CHECK_VERSION (3, 8, 0)
+      gtk_container_add (GTK_CONTAINER (x->menubar_viewport), x->menubar_widget);
+#else
+      gtk_scrolled_window_add_with_viewport (GTK_SCROLLED_WINDOW (x->menubar_viewport), x->menubar_widget);
+#endif
+    }
+  else
+    {
+      if (x->menubar_visible_widget == x->menubar_widget)
+        return;
+
+      x->menubar_visible_widget = x->menubar_widget;
+      orphan_widget (x->menubar_widget);
+      orphan_widget (x->menubar_viewport);
+    }
+
+  gtk_box_pack_start (GTK_BOX (x->vbox_widget),
+                      GTK_WIDGET (x->menubar_visible_widget), FALSE, FALSE, 0);
+  gtk_box_reorder_child (GTK_BOX (x->vbox_widget),
+                         GTK_WIDGET (x->menubar_visible_widget), 0);
+  gtk_widget_show_all (x->menubar_visible_widget);
+}
+
+#if GTK_CHECK_VERSION (3, 16, 0)
+#define MENUBAR_SCROLLBAR_DEFAULT_POLICY GTK_POLICY_EXTERNAL
+#else
+#define MENUBAR_SCROLLBAR_DEFAULT_POLICY GTK_POLICY_NEVER
+#endif
+
+/* Apply the scrollbar mode and related style settings.
+   This also inserts or removes the intervening viewport as necessary
+   and maps any widgets that need mapping. Note that after gtk 3.16
+   we don't need (or want) to remove the scrolledwindow or viewport,
+   it suffices to change their style.  */
+void
+xg_update_frame_menubar_scrollbar_mode (struct frame *f, Lisp_Object mode)
+{
+  GtkStyleContext *style;
+  struct x_output *x = f->output_data.x;
+  GtkScrolledWindow *sw;
+  GtkPolicyType scroll_policy = MENUBAR_SCROLLBAR_DEFAULT_POLICY;
+
+  if (!x->menubar_viewport)
+    return;
+
+  if (EQ (mode, Qautomatic))
+    scroll_policy = GTK_POLICY_AUTOMATIC;
+  else if (EQ (mode, Qalways))
+    scroll_policy = GTK_POLICY_ALWAYS;
+  else if (EQ (mode, Qforced_resize))
+    scroll_policy = GTK_POLICY_NEVER;
+
+  sw = GTK_SCROLLED_WINDOW (x->menubar_viewport);
+  style = gtk_widget_get_style_context (x->menubar_viewport);
+
+#if GTK_CHECK_VERSION(3, 16, 0)
+  /* Always want the scrollable container for capable-enough GTK versions */
+  menubar_scrollbox (f, 1);
+
+  switch (scroll_policy)
+    {
+    case GTK_POLICY_AUTOMATIC:
+    case GTK_POLICY_ALWAYS:
+      gtk_style_context_add_class (style, "mbscroll");
+      gtk_style_context_remove_class (style, "mbtrunc");
+      break;
+    default:
+      gtk_style_context_remove_class (style, "mbscroll");
+      gtk_style_context_add_class (style, "mbtrunc");
+    }
+#else
+  /* In older GTK versions we need to swap out the scrollable container
+     instead since we can't get truncating behaviour and CSS styling is
+     not well supported. */
+  switch (scroll_policy)
+    {
+    case GTK_POLICY_AUTOMATIC:
+    case GTK_POLICY_ALWAYS:
+      menubar_scrollbox (f, 1);
+      gtk_style_context_remove_class (style, "mbtrunc");
+      break;
+    default:
+      menubar_scrollbox (f, 0);
+      gtk_style_context_add_class (style, "mbtrunc");
+    }
+#endif
+
+  gtk_scrolled_window_set_policy (sw, scroll_policy, GTK_POLICY_AUTOMATIC);
+}
+
 /* Recompute all the widgets of frame F, when the menu bar has been
    changed.  */
 
@@ -3450,6 +3616,7 @@ xg_update_frame_menubar (struct frame *f)
 {
   struct x_output *x = f->output_data.x;
   GtkRequisition req;
+  Lisp_Object menuscroll;
 
   if (!x->menubar_widget || gtk_widget_get_mapped (x->menubar_widget))
     return;
@@ -3459,13 +3626,29 @@ xg_update_frame_menubar (struct frame *f)
 
   block_input ();
 
-  gtk_box_pack_start (GTK_BOX (x->vbox_widget), x->menubar_widget,
-                      FALSE, FALSE, 0);
-  gtk_box_reorder_child (GTK_BOX (x->vbox_widget), x->menubar_widget, 0);
+  menuscroll = get_frame_param (f, Qmenu_bar_scrollbar);
+
+  /* Put the menu bar inside a scrolled window so that adding items
+     to the menu bar (such as when entering dired mode or activating
+     a minor more) does not trigger a frame resize:*/
+  x->menubar_viewport = gtk_scrolled_window_new(NULL, NULL);
+
+  /* Leave the keyboard focus where it is when clicking the scrollwindow: */
+#if GTK_CHECK_VERSION (3, 20, 0)
+  gtk_widget_set_focus_on_click (x->menubar_viewport, FALSE);
+#endif
+
+#if GTK_CHECK_VERSION (3, 16, 0)
+  /* If we don't set this then the scrollable keeps focus when the user
+     interacts with the scrollbar, at least until the menubar is clicked.
+     Overlay scrolling is more compact but until the focus problem is fixed
+     it's not livable with. */
+  gtk_scrolled_window_set_overlay_scrolling (GTK_SCROLLED_WINDOW (x->menubar_viewport), FALSE);
+#endif
 
   g_signal_connect (x->menubar_widget, "map", G_CALLBACK (menubar_map_cb), f);
-  gtk_widget_show_all (x->menubar_widget);
-  gtk_widget_get_preferred_size (x->menubar_widget, NULL, &req);
+  xg_update_frame_menubar_scrollbar_mode (f, menuscroll);
+  gtk_widget_get_preferred_size (x->menubar_visible_widget, NULL, &req);
 
   if (FRAME_MENUBAR_HEIGHT (f) != req.height)
     {
@@ -3487,10 +3670,14 @@ free_frame_menubar (struct frame *f)
     {
       block_input ();
 
-      gtk_container_remove (GTK_CONTAINER (x->vbox_widget), x->menubar_widget);
+      discard_widget (x->menubar_widget);
+      discard_widget (x->menubar_viewport);
+
        /* The menubar and its children shall be deleted when removed from
           the container.  */
-      x->menubar_widget = 0;
+      x->menubar_visible_widget = NULL;
+      x->menubar_viewport = NULL;
+      x->menubar_widget = NULL;
       FRAME_MENUBAR_HEIGHT (f) = 0;
       adjust_frame_size (f, -1, -1, 2, 0, Qmenu_bar_lines);
       unblock_input ();
diff --git a/src/gtkutil.h b/src/gtkutil.h
index 7dcd549f5c..96220f27c8 100644
--- a/src/gtkutil.h
+++ b/src/gtkutil.h
@@ -103,6 +103,9 @@ extern void xg_modify_menubar_widgets (GtkWidget *menubar,
                                        GCallback deactivate_cb,
                                        GCallback highlight_cb);
 
+extern void xg_update_frame_menubar_scrollbar_mode (struct frame *f,
+                                                    Lisp_Object mode);
+
 extern void xg_update_frame_menubar (struct frame *f);
 
 extern bool xg_event_is_for_menubar (struct frame *, const XEvent *);
diff --git a/src/xfns.c b/src/xfns.c
index 3da853ede8..9503ae1e1d 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -1601,6 +1601,13 @@ x_set_menu_bar_lines (struct frame *f, Lisp_Object value, Lisp_Object oldval)
   adjust_frame_glyphs (f);
 }
 
+static void
+x_set_menu_bar_scrollbar (struct frame *f, Lisp_Object value, Lisp_Object oldval)
+{
+#ifdef USE_GTK /* menubar resize/scrolling only happens under GTK.  */
+  xg_update_frame_menubar_scrollbar_mode (f, value);
+#endif
+}
 
 /* Set the number of lines used for the tool bar of frame F to VALUE.
    VALUE not an integer, or < 0 means set the lines to zero.  OLDVAL
@@ -3888,7 +3895,9 @@ This function is an internal primitive--use `make-frame' instead.  */)
 		       NILP (Vtool_bar_mode)
 		       ? make_number (0) : make_number (1),
 		       NULL, NULL, RES_TYPE_NUMBER);
-
+  /* How scrolling is handled for oversized (too wide) menu bars.  */
+  x_default_parameter (f, parms, Qmenu_bar_scrollbar, Qnil,
+                       NULL, NULL, RES_TYPE_SYMBOL);
   x_default_parameter (f, parms, Qbuffer_predicate, Qnil,
 		       "bufferPredicate", "BufferPredicate",
 		       RES_TYPE_SYMBOL);
@@ -7536,6 +7545,7 @@ frame_parm_handler x_frame_parm_handlers[] =
   x_set_right_divider_width,
   x_set_bottom_divider_width,
   x_set_menu_bar_lines,
+  x_set_menu_bar_scrollbar,
   x_set_mouse_color,
   x_explicitly_set_name,
   x_set_scroll_bar_width,
diff --git a/src/xterm.h b/src/xterm.h
index f73dd0e25a..ac5f7f08da 100644
--- a/src/xterm.h
+++ b/src/xterm.h
@@ -581,7 +581,11 @@ struct x_output
   /* The widget used for laying out widgets horizontally.  */
   GtkWidget *hbox_widget;
   /* The menubar in this frame.  */
+  GtkWidget *menubar_viewport;
   GtkWidget *menubar_widget;
+  /* If the viewport is in usem this will be the viewport, otherwise it
+     will be the menubar_widget. Used to get height calculations right. */
+  GtkWidget *menubar_visible_widget;
   /* The tool bar in this frame  */
   GtkWidget *toolbar_widget;
   /* True if tool bar is packed into the hbox widget (i.e. vertical).  */
-- 
2.11.0


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: Type: TEXT/x-diff; name=0002-Document-the-new-menu-bar-scrollbar-frame-parameter.patch, Size: 2022 bytes --]

From 489a38cceda02e62dc50367347930713f4454f95 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vivek=20Das=C2=A0Mohapatra?= <vivek@collabora.com>
Date: Thu, 11 Oct 2018 13:48:47 +0100
Subject: [PATCH 2/3] Document the new menu-bar-scrollbar frame parameter

---
 doc/lispref/frames.texi | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/doc/lispref/frames.texi b/doc/lispref/frames.texi
index 2f9bb39886..601749d97e 100644
--- a/doc/lispref/frames.texi
+++ b/doc/lispref/frames.texi
@@ -601,6 +601,10 @@ Frame Layout
 frame unchanged, so the native height of the frame (see below) will
 change instead.
 
+If the menu bar is drawn by GTK then its behavior when it would grow
+wider than the root frame is controlled by the @code{menu-bar-scrollbar}
+parameter (@pxref{Layout Parameters}).
+
 @item Tool Bar
 @cindex internal tool bar
 @cindex external tool bar
@@ -1814,6 +1818,23 @@ Layout Parameters
 (@pxref{Frame Geometry}) allows to derive whether the menu bar actually
 occupies one or more lines.
 
+@vindex menu-bar-scrollbar@r{, a frame parameter}
+@item menu-bar-scrollbar
+The behavior of GTK menu bars when they would otherwise grow wider than
+the frame.  Valid values are:
+@itemize
+@item @code{always} - Scrollbar is present, menu bar scrolls when too wide.
+@item @code{automatic} - Scrollbar appears when menubar grows too wide.
+@item @code{forced-resize} - No scrollbar.  Growing menubar forces a frame resize.
+@item @code{nil} (or any other value)
+@itemize
+@item GTK >= 3.16 - No scrollbar.  Menu bar is truncated if it grows too wide.
+@item GTK < 3,16 - Same behavior as @code{forced-resize}.
+@end itemize
+@end itemize
+It is worth noting that for GTK before 3.16 the scrollbar adds a significant
+amount of vertical padding to the menubar: This appears to be unavoidable.
+
 @vindex tool-bar-lines@r{, a frame parameter}
 @item tool-bar-lines
 The number of lines to use for the tool bar (@pxref{Tool Bar}).  The
-- 
2.11.0


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: Type: TEXT/x-diff; name=0003-Hook-up-menu-bar-scrollbar-functionality-to-customiz.patch, Size: 9030 bytes --]

From 31e687a7c848bbc4e0a7ef34acc4f55a7d5a9004 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vivek=20Das=C2=A0Mohapatra?= <vivek@collabora.com>
Date: Thu, 18 Oct 2018 01:38:05 +0100
Subject: [PATCH 3/3] Hook up menu bar scrollbar functionality to customize &
 Options menu
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

menu-bar-scrollbar-mode custom variable updates default and
initial frame parameters.

menu-bar-scrollbar-mode command cycles the custom variable through
the available/supported values

Options ► Show Hide ► Menu Bar Scroll/Truncate menu connected to
the custom variable.
---
 lisp/menu-bar.el | 139 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 139 insertions(+)

diff --git a/lisp/menu-bar.el b/lisp/menu-bar.el
index e2ebd98119..0dc8757249 100644
--- a/lisp/menu-bar.el
+++ b/lisp/menu-bar.el
@@ -673,6 +673,7 @@ menu-bar-options-save
 		   line-number-mode column-number-mode size-indication-mode
 		   cua-mode show-paren-mode transient-mark-mode
 		   blink-cursor-mode display-time-mode display-battery-mode
+                   menu-bar-scrollbar-mode
 		   ;; These are set by other functions that don't set
 		   ;; the customized state.  Having them here has the
 		   ;; side-effect that turning them off via X
@@ -1042,6 +1043,138 @@ menu-bar-showhide-tool-bar-menu-customize-enable-bottom
   (interactive)
   (menu-bar-set-tool-bar-position 'bottom))
 
+(defcustom menu-bar-scrollbar-mode nil
+      "Specify how GTK menu bars deal with the frame being too narrow to hold them.\n
+Valid values are:
+  `always'        - the menu bar always has a scrollbar
+  `automatic'     - a scrollbar is added when required
+  `forced-resize' - no scrollbar, the frame is forced to resize to accommodate
+                    the menu bar.
+   nil (or any other value) - the menu bar is truncated\n
+Note that prior to GTK 3.16 truncation is not possible and the default
+is equivalent to 'forced-resize.\n
+Do not set this variable directly - use the customize interface to make sure
+that `default-frame-alist', `initial-frame-alist' and all existing frames
+remain in sync."
+      :version "26.2"
+      :type '(choice (const always)
+		     (const automaic)
+		     (const forced-resize)
+		     (const nil))
+      :group 'frames
+      :initialize 'custom-initialize-default
+      :set (lambda (sym val)
+             (setq val (if (memq val '(automatic always forced-resize)) val nil))
+             (set-default sym val)
+             (modify-all-frames-parameters
+	      (list (cons 'menu-bar-scrollbar val)))))
+
+(defun menu-bar-can-be-truncated ()
+  (let (version)
+    (when (boundp 'gtk-version-string)
+      (setq version (mapcar 'string-to-number (split-string gtk-version-string "\\.")))
+      (or (and (eq (car version) 3) (>= (cadr version) 16))
+          (>= (car version) 4)))))
+
+(defun menu-bar-scrollbar-next-mode (mode)
+  "Return the next menu-bar-scrollbar frame parameter value after MODE.
+Takes into account the abilities of the available GTK version."
+  (if (menu-bar-can-be-truncated)
+      (progn
+        (if (not (memq mode '(always automatic forced-resize nil))) (setq mode nil))
+        (cadr (memq mode '(nil automatic always forced-resize nil))))
+    (if (not (memq mode '(always automatic nil))) (setq mode nil))
+    (cadr (memq mode '(nil automatic always nil)))))
+
+(defun menu-bar-scrollbar-mode (&optional mode)
+  "Cycle through scroll/truncate/resize modes for GTK menu bars.\n
+If the optional parameter MODE is specified then apply that instead.
+The new mode is stored in the variable `menu-bar-scrollbar-mode' via
+the custom interface (but not automatically saved).\n
+Returns the new MODE.\n
+NOTE: pass 'default if you want to set the mode explicitly to nil.\n
+See `menu-bar-scrollbar' in Info node `(elisp)Layout Parameters' for details."
+  (interactive)
+  (if mode
+      ;; explicit mode passed, map any non-standard value back to nil
+      (setq mode (car (memq mode '(automatic always forced-resize))))
+    ;; no explicit mode: pick the new value based on our fixed progression:
+    (setq mode (menu-bar-scrollbar-next-mode
+                (or menu-bar-scrollbar-mode 'default))))
+  ;; set, apply but do not save the new value:
+  (customize-set-variable 'menu-bar-scrollbar-mode mode)
+  mode)
+
+(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-forced-resize ()
+  "Resize the frame to accommodate the menu bar."
+  (interactive)
+  (customize-set-variable 'menu-bar-scrollbar-mode 'forced-resize))
+(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-always ()
+  "Add a permanent scrollbar to the menu bar."
+  (interactive)
+  (customize-set-variable 'menu-bar-scrollbar-mode 'always))
+(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-automatic ()
+  "Add a scrollbar to the menu bar when it tries to grow past the frame edge.."
+  (interactive)
+  (customize-set-variable 'menu-bar-scrollbar-mode 'automatic))
+(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-nil ()
+  "Truncate the menu bar to fit the frame."
+  (interactive)
+  (customize-set-variable 'menu-bar-scrollbar-mode 'default))
+
+(when (featurep 'gtk)
+  (defvar menu-bar-showhide-menu-bar-scrollbar-mode-menu
+    (let ((menu (make-sparse-keymap "Menu Bar Scroll/Truncate")))
+
+      (bindings--define-key menu [showhide-menu-bar-scrollbar-mode-forced-resize]
+        '(menu-item "Resize Frame"
+                    menu-bar-showhide-menu-bar-scrollbar-mode-customize-forced-resize
+                    :help "Resize the frame to accommodate the menu bar"
+                    :visible (display-graphic-p)
+                    :button
+                    (:radio . (if (menu-bar-can-be-truncated)
+                                  (eq (frame-parameter
+                                       (menu-bar-frame-for-menubar)
+                                       'menu-bar-scrollbar)
+                                      'forced-resize)
+                                (not (memq (frame-parameter
+                                            (menu-bar-frame-for-menubar)
+                                            'menu-bar-scrollbar)
+                                           '(automatic always)))))))
+
+      (bindings--define-key menu [showhide-menu-bar-scrollbar-mode-always]
+        '(menu-item "Always Scroll"
+                    menu-bar-showhide-menu-bar-scrollbar-mode-customize-always
+                    :help "Always add a scroll bar to the menu bar"
+                    :visible (display-graphic-p)
+                    :button
+                    (:radio . (eq (frame-parameter (menu-bar-frame-for-menubar)
+                                                   'menu-bar-scrollbar)
+                                  'always))))
+
+      (bindings--define-key menu [showhide-menu-bar-scrollbar-mode-automatic]
+        '(menu-item "Automatic"
+                    menu-bar-showhide-menu-bar-scrollbar-mode-customize-automatic
+                    :help "Display a scroll bar only when the menu is too wide"
+                    :visible (display-graphic-p)
+                    :button
+                    (:radio . (eq (frame-parameter (menu-bar-frame-for-menubar)
+                                                   'menu-bar-scrollbar)
+                                  'automatic))))
+
+      (bindings--define-key menu [showhide-menu-bar-scrollbar-mode-truncate]
+        '(menu-item "Truncate"
+                    menu-bar-showhide-menu-bar-scrollbar-mode-customize-nil
+                    :help "Truncate the menubar to fit inside the frame"
+                    :visible (and (display-graphic-p)
+                                  (menu-bar-can-be-truncated))
+                    :button
+                    (:radio . (not (memq
+                                    (frame-parameter (menu-bar-frame-for-menubar)
+                                                     'menu-bar-scrollbar)
+                                    '(automatic always forced-resize))))))
+      menu)))
+
 (when (featurep 'move-toolbar)
   (defvar menu-bar-showhide-tool-bar-menu
     (let ((menu (make-sparse-keymap "Tool Bar")))
@@ -1225,6 +1358,12 @@ menu-bar-showhide-menu
                   :visible (and (display-graphic-p) (fboundp 'x-show-tip))
                   :button (:toggle . tooltip-mode)))
 
+    (when (featurep 'gtk)
+      (bindings--define-key menu [showhide-menu-bar-scrollbar-menu]
+        `(menu-item "Menu Bar Scroll/Truncate"
+                    ,menu-bar-showhide-menu-bar-scrollbar-mode-menu
+                    :visible (display-graphic-p))))
+
     (bindings--define-key menu [menu-bar-mode]
       '(menu-item "Menu Bar" toggle-menu-bar-mode-from-frame
                   :help "Turn menu bar on/off"
-- 
2.11.0

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Robert Pluim]

I donʼt use the menu-bar, so I can't speak to the functionality, but
various documentation nits below. (menu-bar? menubar? menu bar? Iʼm
not sure what the consensus is there)

Vivek Dasmohapatra <vivek@etla.org> writes:

> featurep guards added, defcustom setting emacs version bumped.
>
>
> From 489a38cceda02e62dc50367347930713f4454f95 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Vivek=20Das=C2=A0Mohapatra?= <vivek@collabora.com>
> Date: Thu, 11 Oct 2018 13:48:47 +0100
> Subject: [PATCH 2/3] Document the new menu-bar-scrollbar frame parameter
>
> ---
>  doc/lispref/frames.texi | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
>
> diff --git a/doc/lispref/frames.texi b/doc/lispref/frames.texi
> index 2f9bb39886..601749d97e 100644
> --- a/doc/lispref/frames.texi
> +++ b/doc/lispref/frames.texi
> @@ -601,6 +601,10 @@ Frame Layout
>  frame unchanged, so the native height of the frame (see below) will
>  change instead.
>  
> +If the menu bar is drawn by GTK then its behavior when it would grow
> +wider than the root frame is controlled by the @code{menu-bar-scrollbar}
> +parameter (@pxref{Layout Parameters}).
> +

What is the 'root frame'? Surely the only frame that matters is the
one displaying the menu bar?

>  @item Tool Bar
>  @cindex internal tool bar
>  @cindex external tool bar
> @@ -1814,6 +1818,23 @@ Layout Parameters
>  (@pxref{Frame Geometry}) allows to derive whether the menu bar actually
>  occupies one or more lines.
>  
> +@vindex menu-bar-scrollbar@r{, a frame parameter}
> +@item menu-bar-scrollbar
> +The behavior of GTK menu bars when they would otherwise grow wider than
> +the frame.  Valid values are:
> +@itemize
> +@item @code{always} - Scrollbar is present, menu bar scrolls when
> too wide.

'Scrollbar is always shown' perhaps.

What does 'menu bar scrolls when too wide' mean? If the menu bar is
too wide to be displayed entirely, then the user has to take some
action to see the hidden items. This phrase seems to imply some kind
of automatic behaviour.

> +@item @code{automatic} - Scrollbar appears when menubar grows too
> wide.

'Scrollbar is shown when menubar grows too wide.'

> +@item @code{forced-resize} - No scrollbar.  Growing menubar forces a frame resize.
> +@item @code{nil} (or any other value)

Iʼd drop the 'any other value' portion, so as not to constrain any
future changes. Also I think this is the one time where you use
'menubar' rather than 'menu bar'.

> +@itemize
> +@item GTK >= 3.16 - No scrollbar.  Menu bar is truncated if it grows too wide.
> +@item GTK < 3,16 - Same behavior as @code{forced-resize}.

'3.16' rather than '3,16'


> +@end itemize
> +@end itemize
> +It is worth noting that for GTK before 3.16 the scrollbar adds a significant
> +amount of vertical padding to the menubar: This appears to be unavoidable.
> +

Iʼd write 'this' rather than 'This': itʼs not a separate sentence.

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 748 bytes --]

> What is the 'root frame'? Surely the only frame that matters is the
> one displaying the menu bar?

That is the root frame.

> Iʼd drop the 'any other value' portion, so as not to constrain any
> future changes.

On this specific point, no: I want to clearly document that any unrecognised
value will result in the default behaviour.

As to the rest of the changes: Presumably they can be tidied up when/if
the patches are committed? I don't particularly want to enter an infinite
edit loop here on the BTS (although thanks for the proofreading).

PS: Regarding the capital-after-a-colon question - this is a rigidly
defined area of doubt and uncertainty. There appears to be no hard-and-fast
rule, only whatever's in various house style guides.

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Robert Pluim]

Vivek Dasmohapatra <vivek@etla.org> writes:

>> What is the 'root frame'? Surely the only frame that matters is the
>> one displaying the menu bar?
>
> That is the root frame.

OK

>
>> Iʼd drop the 'any other value' portion, so as not to constrain any
>> future changes.
>
> On this specific point, no: I want to clearly document that any unrecognised
> value will result in the default behaviour.
>

OK

> As to the rest of the changes: Presumably they can be tidied up when/if
> the patches are committed? I don't particularly want to enter an infinite
> edit loop here on the BTS (although thanks for the proofreading).

I was not proposing such a loop, merely offering suggestions that I
thought would aid clarity.

Since weʼre on the subject: I scanned the other patches, and there are
various minor formatting issues there: no double space at the end of
sentence, missing period at the end of sentence, plus some stray "\n"
in lisp doc strings. No need to resend, though :-)

> PS: Regarding the capital-after-a-colon question - this is a rigidly
> defined area of doubt and uncertainty. There appears to be no hard-and-fast
> rule, only whatever's in various house style guides.

Iʼd argue that based on consistency capital letters should only be
used at the start of a sentence, and in this case itʼs a dependent
clause, not a separate sentence. But thatʼs not a very strong rule,
Iʼll admit.

Robert

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Eli Zaretskii]

> Date: Thu, 18 Oct 2018 14:24:14 +0100 (BST)
> From: Vivek Dasmohapatra <vivek@etla.org>
> Cc: 22000@debbugs.gnu.org, David Engster <deng@randomsample.de>
> 
> > What is the 'root frame'? Surely the only frame that matters is the
> > one displaying the menu bar?
> 
> That is the root frame.

We don't have such terminology in Emacs.

Maybe I misunderstand you: what other frames, except "root frames" do
you see in Emacs?

> PS: Regarding the capital-after-a-colon question - this is a rigidly
> defined area of doubt and uncertainty. There appears to be no hard-and-fast
> rule, only whatever's in various house style guides.

FWIW, I find the capital-letter style here jarring.

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Eli Zaretskii]

> Date: Thu, 18 Oct 2018 18:08:42 +0100 (BST)
> From: Vivek Dasmohapatra <vivek@etla.org>
> cc: rpluim@gmail.com, 22000@debbugs.gnu.org, deng@randomsample.de
> 
> > Maybe I misunderstand you: what other frames, except "root frames" do
> > you see in Emacs?
> 
> I had to call it something - root window already means something else in X.
> I just meant the top-level enclosing widget. I am happy do describe it with
> any reasonably accurate term.

I guess I'm asking why not just say "frame"?

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Stephen Berman]

On Thu, 18 Oct 2018 14:48:21 +0200 Robert Pluim <rpluim@gmail.com> wrote:

> I donʼt use the menu-bar, so I can't speak to the functionality, but
> various documentation nits below. (menu-bar? menubar? menu bar? Iʼm
> not sure what the consensus is there)

The status quo in the Emacs manual favors two words, also for related
terms:

$ grep -i menubar emacs.info | wc -l
27
$ grep -i menu-bar emacs.info | wc -l
14
$ grep -i "menu bar" emacs.info | wc -l
80
$ grep -i scrollbar emacs.info | wc -l
10
$ grep -i scroll-bar emacs.info | wc -l
19
$ grep -i "scroll bar" emacs.info | wc -l
72
$ grep -i toolbar emacs.info | wc -l
3
$ grep -i tool-bar emacs.info | wc -l
8
$ grep -i "tool bar" emacs.info | wc -l
48

(Though as Ralph Waldo Emerson (I think) said, consistency is the
hobgoblin of small minds.  Or is that "hob-goblin" or "hob goblin"?)

Steve Berman

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Robert Pluim]

Stephen Berman <stephen.berman@gmx.net> writes:

> On Thu, 18 Oct 2018 14:48:21 +0200 Robert Pluim <rpluim@gmail.com> wrote:
>
>> I donʼt use the menu-bar, so I can't speak to the functionality, but
>> various documentation nits below. (menu-bar? menubar? menu bar? Iʼm
>> not sure what the consensus is there)
>
> The status quo in the Emacs manual favors two words, also for related
> terms:
>
> $ grep -i menubar emacs.info | wc -l
> 27
> $ grep -i menu-bar emacs.info | wc -l
> 14
> $ grep -i "menu bar" emacs.info | wc -l
> 80
> $ grep -i scrollbar emacs.info | wc -l
> 10
> $ grep -i scroll-bar emacs.info | wc -l
> 19
> $ grep -i "scroll bar" emacs.info | wc -l
> 72
> $ grep -i toolbar emacs.info | wc -l
> 3
> $ grep -i tool-bar emacs.info | wc -l
> 8
> $ grep -i "tool bar" emacs.info | wc -l
> 48

I suspect quite a few of those matches are commands or variables, so
not that easy to fix.

> (Though as Ralph Waldo Emerson (I think) said, consistency is the
> hobgoblin of small minds.  Or is that "hob-goblin" or "hob goblin"?)

Indeed.

Robert

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Eli Zaretskii]

> Date: Thu, 18 Oct 2018 13:23:26 +0100 (BST)
> From: Vivek Dasmohapatra <vivek@etla.org>
> cc: 22000@debbugs.gnu.org, David Engster <deng@randomsample.de>, 
>     "eliz@gnu.org" <eliz@gnu.org>
> 
> +/* Sets up the menubar style for scrolling/non-scrolling modes.
> +   Reparents the menubar directly into the vbox for non-scrolling
> +   mode and adds a scrolledwindow+viewport for scrolling modes.  */

This commentary is n ot in the style we (and you elsewhere in the
patch) use: you should say "Set up", not "Sets up".

> +#if GTK_CHECK_VERSION (3, 8, 0)
> +      gtk_container_add (GTK_CONTAINER (x->menubar_viewport), x->menubar_widget);
> +#else
> +      gtk_scrolled_window_add_with_viewport (GTK_SCROLLED_WINDOW (x->menubar_viewport), x->menubar_widget);

Please break long lines into several shorter ones.

> +#if GTK_CHECK_VERSION(3, 16, 0)
> +  /* Always want the scrollable container for capable-enough GTK versions */
> +  menubar_scrollbox (f, 1);

Comments should be complete sentences, start with a capital letter,
and end in a period and 2 spaces.

> +@itemize
> +@item @code{always} - Scrollbar is present, menu bar scrolls when too wide.
> +@item @code{automatic} - Scrollbar appears when menubar grows too wide.
> +@item @code{forced-resize} - No scrollbar.  Growing menubar forces a frame resize.

This is not the correct way of using @itemize.  You should do this
instead:

  @itemize
  @item
  @code{always} - Scrollbar is present, menu bar scrolls when too wide.
  @item
  @code{automatic} - Scrollbar appears when menubar grows too wide.

etc.  (Actually, I'd suggest using "@table @code" here, not @itemize.)

Also, please use "--" for an en-dash, not a single "-".

> +(defcustom menu-bar-scrollbar-mode nil
> +      "Specify how GTK menu bars deal with the frame being too narrow to hold them.\n
> +Valid values are:
> +  `always'        - the menu bar always has a scrollbar
> +  `automatic'     - a scrollbar is added when required
> +  `forced-resize' - no scrollbar, the frame is forced to resize to accommodate
> +                    the menu bar.
> +   nil (or any other value) - the menu bar is truncated\n
> +Note that prior to GTK 3.16 truncation is not possible and the default
> +is equivalent to 'forced-resize.\n

Do you really need these explicit \n newlines?

> +(defun menu-bar-scrollbar-mode (&optional mode)
> +  "Cycle through scroll/truncate/resize modes for GTK menu bars.\n
> +If the optional parameter MODE is specified then apply that instead.
> +The new mode is stored in the variable `menu-bar-scrollbar-mode' via
> +the custom interface (but not automatically saved).\n
> +Returns the new MODE.\n
> +NOTE: pass 'default if you want to set the mode explicitly to nil.\n

Likewise here.

More generally, shouldn't this mode have "gtk" somewhere in the name?
Or, if we hope to implement it for other toolkits at some future date,
the doc string should not say "GTK menu bars", it should say "menu
bars" and then have a note that this currently has effect only with
GTK menus.

> +(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-forced-resize ()
> +  "Resize the frame to accommodate the menu bar."
> +  (interactive)
> +  (customize-set-variable 'menu-bar-scrollbar-mode 'forced-resize))
> +(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-always ()
> +  "Add a permanent scrollbar to the menu bar."
> +  (interactive)
> +  (customize-set-variable 'menu-bar-scrollbar-mode 'always))
> +(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-automatic ()
> +  "Add a scrollbar to the menu bar when it tries to grow past the frame edge.."
> +  (interactive)
> +  (customize-set-variable 'menu-bar-scrollbar-mode 'automatic))
> +(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-nil ()
> +  "Truncate the menu bar to fit the frame."
> +  (interactive)
> +  (customize-set-variable 'menu-bar-scrollbar-mode 'default))

I think doc strings of these functions are too laconic for interactive
functions.

Thanks.

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1897 bytes --]

>> +(defcustom menu-bar-scrollbar-mode nil
>> +      "Specify how GTK menu bars deal with the frame being too narrow to hold them.\n
>> +Valid values are:
>> +  `always'        - the menu bar always has a scrollbar
>> +  `automatic'     - a scrollbar is added when required
>> +  `forced-resize' - no scrollbar, the frame is forced to resize to accommodate
>> +                    the menu bar.
>> +   nil (or any other value) - the menu bar is truncated\n
>> +Note that prior to GTK 3.16 truncation is not possible and the default
>> +is equivalent to 'forced-resize.\n
>
> Do you really need these explicit \n newlines?

I wouldn't say need but I find they make the documentation more readable, 
per item 3 in (elisp)Top > Tips > Documentation tips … D.6 Tips for…

> More generally, shouldn't this mode have "gtk" somewhere in the name?
> Or, if we hope to implement it for other toolkits at some future date,
> the doc string should not say "GTK menu bars", it should say "menu
> bars" and then have a note that this currently has effect only with
> GTK menus.

I prefer the second option, I will adjust the docstrings accordingly.

>> +(defun menu-bar-showhide-menu-bar-scrollbar-mode-customize-nil ()
>> +  "Truncate the menu bar to fit the frame."
>> +  (interactive)
>> +  (customize-set-variable 'menu-bar-scrollbar-mode 'default))
>
> I think doc strings of these functions are too laconic for interactive
> functions.

AIUI they are interactive purely because that is a requirement for the
way they are used by the menu infrastructure, not because they are
intended to be used as commands with M-x or similar by the user.

The other …-customize-… shim commands in that file are similarly laconically
documented. However if the objection still stands, I will add more verbose
docstrings.

I will make the other changes suggested (to which I have not responded
individually here).

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Eli Zaretskii]

> Date: Thu, 18 Oct 2018 18:26:34 +0100 (BST)
> From: Vivek Dasmohapatra <vivek@etla.org>
> cc: rudalics@gmx.at, 22000@debbugs.gnu.org, deng@randomsample.de
> 
> >> +   nil (or any other value) - the menu bar is truncated\n
> >> +Note that prior to GTK 3.16 truncation is not possible and the default
> >> +is equivalent to 'forced-resize.\n
> >
> > Do you really need these explicit \n newlines?
> 
> I wouldn't say need but I find they make the documentation more readable, 
> per item 3 in (elisp)Top > Tips > Documentation tips … D.6 Tips for…

Sure, but why not have them literally, so that reading the doc string
in the code will also be easier.  Like this:

  (defun menu-bar-scrollbar-mode (&optional mode)
    "Cycle through scroll/truncate/resize modes for GTK menu bars.

  If the optional parameter MODE is specified then apply that instead.
  The new mode is stored in the variable `menu-bar-scrollbar-mode' via
  the custom interface (but not automatically saved).

  Returns the new MODE.

  NOTE: pass 'default if you want to set the mode explicitly to nil.

  See `menu-bar-scrollbar' in Info node `(elisp)Layout Parameters' for details."

> I will make the other changes suggested (to which I have not responded
> individually here).

Thanks.

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

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?).

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Drew Adams]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Eli Zaretskii]

> Date: Thu, 18 Oct 2018 12:55:09 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 22000@debbugs.gnu.org, deng@randomsample.de
> 
> FWIW - AFAIK, it is not Emacs convention to add a blank line between
> the first and second lines of text in a doc string.

Quite a few of doc strings do leave an empty line there, and I find
nothing wrong with that.

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Eli Zaretskii]

> Date: Thu, 18 Oct 2018 10:06:27 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 22000@debbugs.gnu.org, David Engster <deng@randomsample.de>, 
>  "eliz@gnu.org" <eliz@gnu.org>
> 
>  > New patch series - I think this has all the features and functionality
>  > discussed so far.
> 
> Eli, I think this should go to the release branch.  If it introduces any
> problems, we should find out soon enough - I think that most of our GTK
> users leave the menu bar on.  But it is not just a cosmetic change.

Not a cosmetic change, indeed.

I realize that it fixes an annoying misfeature, but it does so by
introducing a significant new feature which requires quite a few code
lines.  For a problem that AFAIU has been with us since time
immemoriam, I'm really uneasy with putting this on emacs-26.  But I'm
fully prepared to hear arguments to the contrary.

Thanks.

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Robert Pluim]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 18 Oct 2018 10:06:27 +0200
>> From: martin rudalics <rudalics@gmx.at>
>> CC: 22000@debbugs.gnu.org, David Engster <deng@randomsample.de>, 
>>  "eliz@gnu.org" <eliz@gnu.org>
>> 
>>  > New patch series - I think this has all the features and functionality
>>  > discussed so far.
>> 
>> Eli, I think this should go to the release branch.  If it introduces any
>> problems, we should find out soon enough - I think that most of our GTK
>> users leave the menu bar on.  But it is not just a cosmetic change.
>
> Not a cosmetic change, indeed.
>
> I realize that it fixes an annoying misfeature, but it does so by
> introducing a significant new feature which requires quite a few code
> lines.  For a problem that AFAIU has been with us since time
> immemoriam, I'm really uneasy with putting this on emacs-26.  But I'm
> fully prepared to hear arguments to the contrary.

Iʼve tried the patch now, and am seeing some minor display glitches
from emacs -Q. The space allocated for the menu bar seems slightly too
small, resulting in a dotted line underneath it, see screenshot. This
is with gtk 3.22.30.


[-- Attachment #2: Selection_045.png --]
[-- Type: image/png, Size: 14740 bytes --]

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

 > 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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

>> Iʼve tried the patch now,
>
> Thank you.  Please try also customizing the option from the menu bar
> and please also try its main feature: Make the frame sufficently
> narrow, type M-x dired RET RET, and test whether the menu bar gets
> truncated instead of resizing the frame.
>

Something very strange is going on: menu-bar-scrollbar-mode is nil by
default, so why am I seeing a scrollbar at all?

Even stranger: with KDE I see the scrollbar, but running the same
emacs binary under GNOME I donʼt (and the menubar is truncated when
the frame is too narrow, so the functionality is fine).

>>  and am seeing some minor display glitches
>> from emacs -Q. The space allocated for the menu bar seems slightly too
>> small, resulting in a dotted line underneath it, see screenshot. This
>> is with gtk 3.22.30.
>
> From that screenshot it's also evident that descenders are truncated,
> in particular the "p" in Options, Help ...

Yes. Iʼm thinking there should be no scrollbar at all.

<Coffee kicks in>

Iʼm seeing a *vertical* scroll bar. So probably this is just a slight
miscalculation of the menubar height (but then why is it different
under KDE than GNOME?). Would it make sense to start playing with
gtkutil.c:MENUBAR_STYLESHEET ?

Robert

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

 > 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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

>> Something very strange is going on: menu-bar-scrollbar-mode is nil by
>> default, so why am I seeing a scrollbar at all?
>
> Can you please describe the steps you performed?  Is this with -Q or
> in a session where you turned the menu bar on later?

emacs -Q. But I was confused about the scrollbar :-)

>> Even stranger: with KDE I see the scrollbar, but running the same
>> emacs binary under GNOME I donʼt (and the menubar is truncated when
>> the frame is too narrow, so the functionality is fine).
>
> Is there no way to turn the scroll bar off under KDE?  Can you turn
> the scroll bar on under GNOME?

Under GNOME, I see truncation when the frame is too narrow. If I set
menu-bar-scrollbar-mode to 'always', I get a horizontal scrollbar when
the frame is too narrow. (I haven't retried KDE yet).

So itʼs all working fine, except for the visual glitch under KDE.

>> Yes. Iʼm thinking there should be no scrollbar at all.
>>
>> <Coffee kicks in>
>>
>> Iʼm seeing a *vertical* scroll bar. So probably this is just a slight
>> miscalculation of the menubar height (but then why is it different
>> under KDE than GNOME?). Would it make sense to start playing with
>> gtkutil.c:MENUBAR_STYLESHEET ?
>
> I think so.  But I'd like to see at least one or two other persons
> with sufficiently new GTKs kick in (Stephen, pretty please) so we get
> a more complete picture of which problems may occur.

  ".mbtrunc  * { border-width: 1px; margin-top: -2px; margin-bottom: -2px; }\n" \

Iʼm thinking maybe that margin-bottom should be 0px or something? Iʼll
see if I can try that later.

Robert

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Robert Pluim]

Robert Pluim <rpluim@gmail.com> writes:

>>> Iʼm seeing a *vertical* scroll bar. So probably this is just a slight
>>> miscalculation of the menubar height (but then why is it different
>>> under KDE than GNOME?). Would it make sense to start playing with
>>> gtkutil.c:MENUBAR_STYLESHEET ?
>>
>> I think so.  But I'd like to see at least one or two other persons
>> with sufficiently new GTKs kick in (Stephen, pretty please) so we get
>> a more complete picture of which problems may occur.
>
>   ".mbtrunc  * { border-width: 1px; margin-top: -2px; margin-bottom: -2px; }\n" \
>
> Iʼm thinking maybe that margin-bottom should be 0px or something? Iʼll
> see if I can try that later.

Further testing under KDE shows three things:

1. I get a vertical scrollbar on the right for the echo
   area/minibuffer line but not the menubar using emacs -Q on
   unmodified emacs-26, so that was not introduced by this patch

2. In unmodified emacs-26, the line separating the menu bar from the
   tool bar is solid, not dotted

3. I can get rid of the menu bar truncation issue by setting
   margin-bottom to 10px (but I still have the vertical scrollbar).


Robert

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

 > 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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Robert Pluim]

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

martin rudalics <rudalics@gmx.at> writes:

>> Further testing under KDE shows three things:
>>
>> 1. I get a vertical scrollbar on the right for the echo
>>     area/minibuffer line but not the menubar using emacs -Q on
>>     unmodified emacs-26, so that was not introduced by this patch
>
> Hmmm... Could you investigatte why this happens?  Note that the echo
> area/minibuffer window by default hay a vertical scroll bar, just that
> it is hidden when the window height is less than the minimum length of
> the slider, see the following part of gtkutil.c:
>
>       if (hidden)
>         {
>           /* No room.  Hide scroll bar as some themes output a warning if
>              the height is less than the min size.  */
>           gtk_widget_hide (wparent);
>           gtk_widget_hide (wscroll);
>         }
>
> If you put a breakpoint at the 'if' you should see what's different
> between GNOME and KDE.

Under KDE the minimum slider length is 21, under GNOME itʼs the same,
but the reported height of the echo area is > msl under KDE. This
looks like another scaling issue (except in this case the scale factor
reported by GTK is 1, so I can't do anything to fix it).

>> 2. In unmodified emacs-26, the line separating the menu bar from the
>>     tool bar is solid, not dotted
>>
>> 3. I can get rid of the menu bar truncation issue by setting
>>     margin-bottom to 10px
>
> When you do that does the spearator become solid again?

No, then I get both a solid separator and a dotted one just underneath
it:


[-- Attachment #2: Selection_046.png --]
[-- Type: image/png, Size: 12754 bytes --]

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


>> (but I still have the vertical scrollbar).
>
> Funny.  I suppose that vertical menu bar scroll bar is of no use, that
> is, you don't get any truncated items in a second row?

Correct.

Robert

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

 > 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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

>> Under KDE the minimum slider length is 21, under GNOME itʼs the same,
>> but the reported height of the echo area is > msl under KDE. This
>> looks like another scaling issue (except in this case the scale factor
>> reported by GTK is 1, so I can't do anything to fix it).
>
> So which of the following interpretations is correct?
>
> (1) The display artifacts happen regardless of whether scaling is
> on or off.
>
> (2) The display artifacts happen only when scaling is on.
>
> (3) The display artifacts happen only when scaling is on and Emacs is
> not aware of that fact because the reported scale factor is 1.

Itʼs (3). If I specifically run emacs with GDK_SCALE=2, then I see no
vertical scrollbar for the echo area, as expected.

Maybe I should just run GNOME all the time :-)

Robert

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

>>> (3) The display artifacts happen only when scaling is on and Emacs is
>>> not aware of that fact because the reported scale factor is 1.
>>
>> Itʼs (3). If I specifically run emacs with GDK_SCALE=2, then I see no
>> vertical scrollbar for the echo area, as expected.
>
> In this case Vivek might not be the right addressee for this problem
> because he probably does not scale.  Provided the problem goes away
> when you use 'forced-resize'.  Otherwise, he should care.

I donʼt understand how this could be Vivek's issue in any case: this
particular problem existed already in emacs-26.

Now the vertical scrollbar on the right of the menubar, *that* might
be Vivek's to solve (presumably thereʼs a need to tell the menubar
widget not to add that scrollbar).

Robert

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

 > 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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

>> I donʼt understand how this could be Vivek's issue in any case: this
>> particular problem existed already in emacs-26.
>
> I slowly begin to understand the issue.  The vertical scroll bar shows
> up as soon as the menu bar window gets high enough to make the slider
> fit.  Is that correct?  One thing I do not understand then: Do we
> really call xg_update_scrollbar_pos for the menu bar's scroll bar?  If
> so, how?  IIUC the scroll bar code is oblivious to menu bar windows.
>

The vertical scroll bar shows up immediately the menu bar is
drawn. xg_update_scrollbar_pos is not called for it at all. But see below.

>> Now the vertical scrollbar on the right of the menubar, *that* might
>> be Vivek's to solve (presumably thereʼs a need to tell the menubar
>> widget not to add that scrollbar).
>
> Agreed.

And in fact, after digging through some more GTK docs, itʼs as simple
as changing

  gtk_scrolled_window_set_policy (sw, scroll_policy, GTK_POLICY_AUTOMATIC);

to

  gtk_scrolled_window_set_policy (sw, scroll_policy, GTK_POLICY_NEVER);
  
in Vivek's patch. Vivek, does that make sense? I donʼt think we ever
want the menu bar to show a vertical scroll bar.

Note that this also fixes the visual glitch that I saw with the
dotted line and the menubar text descender truncation.

Regards

Robert

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 272 bytes --]

> And in fact, after digging through some more GTK docs, itʼs as simple
> as changing
>
>  gtk_scrolled_window_set_policy (sw, scroll_policy, GTK_POLICY_AUTOMATIC);
>

Yes, I may be able to simplify the codepaths for earlier versions of GTK 
too, currently testing that.

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Stephen Berman]

On Fri, 19 Oct 2018 10:34:08 +0200 martin rudalics <rudalics@gmx.at> wrote:

>> Something very strange is going on: menu-bar-scrollbar-mode is nil by
>> default, so why am I seeing a scrollbar at all?
>
> Can you please describe the steps you performed?  Is this with -Q or
> in a session where you turned the menu bar on later?
>
>> Even stranger: with KDE I see the scrollbar, but running the same
>> emacs binary under GNOME I donʼt (and the menubar is truncated when
>> the frame is too narrow, so the functionality is fine).
>
> Is there no way to turn the scroll bar off under KDE?  Can you turn
> the scroll bar on under GNOME?
>
>> Yes. Iʼm thinking there should be no scrollbar at all.
>>
>> <Coffee kicks in>
>>
>> Iʼm seeing a *vertical* scroll bar. So probably this is just a slight
>> miscalculation of the menubar height (but then why is it different
>> under KDE than GNOME?). Would it make sense to start playing with
>> gtkutil.c:MENUBAR_STYLESHEET ?
>
> I think so.  But I'd like to see at least one or two other persons
> with sufficiently new GTKs kick in (Stephen, pretty please) so we get
> a more complete picture of which problems may occur.

I've applied the patches in
https://lists.gnu.org/archive/html/bug-gnu-emacs/2018-10/msg00514.html
to current master and everything seems to be working as it should.  This
is with GTK+ 3.22.30 and Openbox using several GNOME libraries; I don't
have a complete GNOME DE but I may be able to try with KDE over the
weekend.

There are a couple of visual oddities: when the `menu-bar-scrollbar'
frame parameter has the value nil or `forced-resize' (or when the item
"Menu Bar Scroll/Truncate" of the Options->Show/Hide menu is set to
"Truncate" or "Resize Frame"), then there is no thin dividing line
between the menu bar and the tool bar (in contrast to Emacs built
without this patchset), and in addition, when a menu bar menu is open,
the dividing lines in the menu are rather thick; but when the
`menu-bar-scrollbar' frame parameter has the value `automatic', the thin
dividing line between the menu bar and the tool bar is displayed (and
the menu bar itself is noticeably thicker than in Emacs built without
this patchset), and the dividing lines in an open menu are thinner,
though not as thin as the line between the menu and tool bars (in Emacs
built without this patchset the menu dividers are just as thin as the
the divider between the menu and tool bars); with the parameter value
`always' the scroll bar replaces the dividing line between the menu and
tool bars, and the menu dividers have the same thickness as with the
`automatic' setting.

Steve Berman

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Stephen Berman]

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

On Fri, 19 Oct 2018 15:44:21 +0100 (BST) Vivek Dasmohapatra <vivek@etla.org> wrote:

>> There are a couple of visual oddities: when the `menu-bar-scrollbar'
>> frame parameter has the value nil or `forced-resize' (or when the item
>
> Could you grab screenshots (just the rectangle around the glitch will
> suffice - don't need the whole X window or screen)?
>
> Makes it easier to compare/debug/etc.

Here's a screenshot showing the the menu and tool bars in Emacs without
your patches (left), with patches and menu-bar-scrollbar set to
`automatic' (middle) and set to nil (right):


[-- Attachment #2: menubar1.png --]
[-- Type: image/png, Size: 8334 bytes --]

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


I don't know how to grab a screenshot with an open menu -- as soon as
the menu loses focus (needed to run the screenshot program) it
disappears.  So I photographed the screen and grabbed a screenshot of the
images to reduce the size, though it's still more than 500kB and the
quality is poor -- sorry, but maybe it's good enough to see the issues:


[-- Attachment #4: menubar2.png --]
[-- Type: image/png, Size: 578985 bytes --]

[-- Attachment #5: Type: text/plain, Size: 14 bytes --]


Steve Berman

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

 > 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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[martin rudalics]

 > 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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Eli Zaretskii]

> Date: Thu, 18 Oct 2018 18:40:50 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: vivek@etla.org, 22000@debbugs.gnu.org, deng@randomsample.de
> 
> My sole argument is that the feature does not introduce any hidden or
> subtle changes.  As long as users have a recent enough GTK installed
> and use menu bars any bugs should be easy to find.  The glitch Robert
> has detected is a proof for this claim (my GTK was too old for that).
> 
> In either case I'll be just happy to put this problem to a rest - on
> the release branch or on master.

Oh, I'm quite sure we want this on master, I'm just struggling with
the idea of having all that non-trivial code on the release branch.

Does anyone else have an opinion, or can offer one?

Thanks.

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Robert Pluim]

Vivek Dasmohapatra <vivek@etla.org> writes:

>> Oh, I'm quite sure we want this on master, I'm just struggling with
>> the idea of having all that non-trivial code on the release branch.
>>
>> Does anyone else have an opinion, or can offer one?
>
> Only that I find the current size-jitter extremely annoying, which
> is admittedly a very subjective thing. The actual merge window does
> not matter so much to me because, well, I already have a patched
> emacs on my system(s) by this point.

In favour of putting it on emacs-26 is that it resolves the spewing of

Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion
'extra_space >= 0' failed

when I run emacs with GDK scaling.

Robert

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  22000@debbugs.gnu.org,  deng@randomsample.de
> Date: Fri, 19 Oct 2018 09:26:28 +0200
> 
> In favour of putting it on emacs-26 is that it resolves the spewing of
> 
> Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion
> 'extra_space >= 0' failed
> 
> when I run emacs with GDK scaling.

Thanks.  I understand the advantages of the changeset, what I'm not
sure about is whether these advantages outweigh the danger in putting
such non-trivial changes on the release branch.  The glitches reported
by you and others just in the last two days seem to indicate that we
will be in for more surprises, don't you think?

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  22000@debbugs.gnu.org,  deng@randomsample.de
>> Date: Fri, 19 Oct 2018 09:26:28 +0200
>> 
>> In favour of putting it on emacs-26 is that it resolves the spewing of
>> 
>> Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion
>> 'extra_space >= 0' failed
>> 
>> when I run emacs with GDK scaling.
>
> Thanks.  I understand the advantages of the changeset, what I'm not
> sure about is whether these advantages outweigh the danger in putting
> such non-trivial changes on the release branch.  The glitches reported
> by you and others just in the last two days seem to indicate that we
> will be in for more surprises, don't you think?

Yes. From painful experience various versions of GTK have different
behaviours that aren't detected until the changes are more widely
deployed (but you know that :-) )

Robert

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 47 bytes --]

Try adding this to the latest -compact series.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: TEXT/x-diff; name=0008-Manually-wrap-the-menu-bar-in-a-viewport-for-GTK-3.8.patch, Size: 1060 bytes --]

From 9160f9f1ae7d9f7501a3e6fb5113ba115fb8ccb4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vivek=20Das=C2=A0Mohapatra?= <vivek@collabora.com>
Date: Fri, 12 Oct 2018 19:31:05 +0100
Subject: [PATCH 8/8] Manually wrap the menu bar in a viewport for GTK 3.8-

Versions of GTK prior to 3.8 cannot add non-scrollable
widgets to a scrolled window without a manually added viewport.
---
 src/gtkutil.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/src/gtkutil.c b/src/gtkutil.c
index 3498d14fe1..cd8438f86a 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -3547,7 +3547,11 @@ xg_update_frame_menubar (struct frame *f)
   gtk_scrolled_window_set_overlay_scrolling (sw, FALSE);
 #endif
 
+#if GTK_CHECK_VERSION (3, 8, 0)
   gtk_container_add (GTK_CONTAINER (sw), x->menubar_widget);
+#else
+  gtk_scrolled_window_add_with_viewport (sw, x->menubar_widget);
+#endif
 
   gtk_box_pack_start (GTK_BOX (x->vbox_widget), GTK_WIDGET(sw), FALSE, FALSE, 0);
   gtk_box_reorder_child (GTK_BOX (x->vbox_widget), GTK_WIDGET(sw), 0);
-- 
2.11.0

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 562 bytes --]

> for users who want the resize problem get fixed and who are willing to
> pay for that with a higher menu bar.  And one option value (say
> 'resize') for users who can live with the resizing problem but care more
> about the height of the menu bar.

I've used a CSS provider to strip away all the extra space. I have to put
a little bit back to prevent a UI focus bug when the scrollbar is present
but it's still a lot more compact than it was: Attached screenshot shows
new / new+scrollbar / old - as you can see new w/o scrollbars is the same
height as old.


[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 6036 bytes --]

[-- Attachment #3: Type: IMAGE/png, Size: 4788 bytes --]

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Drew Adams]

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

bug#22000: Patch addressing the menu-bar frame-resize interaction

[Eli Zaretskii]

> Date: Sat, 20 Oct 2018 16:58:37 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: vivek@etla.org, 22000@debbugs.gnu.org, deng@randomsample.de
> 
> > > FWIW - AFAIK, it is not Emacs convention to add a blank line 
> > > between the first and second lines of text in a doc string.
> > 
> > Quite a few of doc strings do leave an empty line there, and I find
> > nothing wrong with that.
> 
> There are quite a few places in Emacs where things
> are done in a less than ideal or conventional way.
> Nothing-wrong versus room-for-improvement, perhaps.

It's okay to think that style is not ideal, but please don't represent
the other style as our guidelines when they aren't.  We should
distinguish between our personal opinions and the project's policy.