Re: Menus with more items than the TTY can display

[martin rudalics]

> How about putting a breakpoint in resize_mini_window, and reporting
> the backtrace (including Lisp backtrace) when it breaks?

This should work but fails for some reason I can't explain.  Recall my
earlier observation that the behavior does _not_ occur when I set
`resize-mini-windows' to nil.  So I'd just have to check where this
variable's settings may affect the course of events and I will have
found the culprit.  I see few such places:

- The one in xdisp.c's resize_mini_window around line 10450 where we
  return immediately when this variable is nil.

- The ones in window.el.  All these seem to go through
  `window--resize-mini-window' which ends up in calling
  `resize-mini-window-internal'.  Putting a breakpoint there gets me no
  hits.  So I exclude this.

- The one in `display-message-or-buffer' should be caught in
  resize_mini_window IIUC.  Excluded as well.

This means that resize_mini_window is indeed the only candidate and I
put a breakpoint there at if (!FRAME_MINIBUF_ONLY_P (f)).

Now to reproduce the behavior, I start emacs in the terminal, remove the
terminal's menu to be able to pass F10 to emacs, attach gdb to the
terminal's emacs, provoke an end of buffer message in the terminal to
verify that the breakpoint is reached at all, hit F10 in the terminal
and scroll the menu.  Now from the time I hit F10 until I hit it again
the breakpoint is _not_ reached.  The following is an IMO meaningless
backtrace after hitting F10 the second time:


#0  resize_mini_window (w=0xd12f28, exact_p=0) at xdisp.c:10465
#1  0x00000000004502c8 in display_echo_area_1 (a1=13709096, a2=13619698) at 
xdisp.c:10357
#2  0x000000000044f998 in with_echo_area_buffer (w=0xd12f28, which=0, fn=0x450290 
<display_echo_area_1>, a1=13709096, a2=13619698) at xdisp.c:10147
#3  0x0000000000450258 in display_echo_area (w=0xd12f28) at xdisp.c:10327
#4  0x000000000045163b in echo_area_display (update_frame_p=0) at xdisp.c:10831
#5  0x0000000000454bfa in redisplay_internal () at xdisp.c:13103
#6  0x000000000045380d in redisplay () at xdisp.c:12699
#7  0x0000000000550163 in read_char (commandflag=1, map=13594294, 
prev_event=13619698, used_mouse_menu=0x7fffc22d17ef, end_time=0x0) at 
keyboard.c:2573
#8  0x000000000055e9a8 in read_key_sequence (keybuf=0x7fffc22d19d0, bufsize=30, 
prompt=13619698, dont_downcase_last=false, can_return_switch_frame=true, 
fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9115
#9  0x000000000054d114 in command_loop_1 () at keyboard.c:1431
#10 0x00000000005eb38b in internal_condition_case (bfun=0x54cd21 <command_loop_1>, 
handlers=13679474, hfun=0x54c4f8 <cmd_error>) at eval.c:1331
#11 0x000000000054c9a4 in command_loop_2 (ignore=13619698) at keyboard.c:1158
#12 0x00000000005ea804 in internal_catch (tag=13675202, func=0x54c97e 
<command_loop_2>, arg=13619698) at eval.c:1097
#13 0x000000000054c954 in command_loop () at keyboard.c:1137
#14 0x000000000054c003 in recursive_edit_1 () at keyboard.c:776
#15 0x000000000054c1e8 in Frecursive_edit () at keyboard.c:840
#16 0x000000000054a178 in main (argc=3, argv=0x7fffc22d1e78) at emacs.c:1577

Lisp Backtrace:
"redisplay_internal (C function)" (0xcee798)


So this is a complete mystery to me.  Is it possible that toggling F10
suppresses any signals from the terminal to the debugger?

martin