Re: Menus with more items than the TTY can display

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 17 Oct 2013 11:28:47 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: dmantipov@yandex.ru, emacs-devel@gnu.org
> 
> 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.

So something else seems to be at work here.

If you don't set resize-mini-windows to nil, but instead set
max-mini-window-height to 1, does the problem also go away?

Another idea would be to ifdef away this fragment from term.c:

      if ((menu_help_message || prev_menu_help_message)
	  && menu_help_message != prev_menu_help_message)
	{
	  help_callback (menu_help_message,
			 menu_help_paneno, menu_help_itemno);
	  tty_hide_cursor (tty);
	  fflush (tty->output);
	  prev_menu_help_message = menu_help_message;
	}

which disables help-echo in the menu, and see if the problem is gone
even without customizing resize-mini-windows.  If it is, then stepping
into the help_callback call might tell who causes the problem.

If disabling help-echo does not make the problem go away, there's
something else that causes resizing, and perhaps you will be able to
spot that without help-echo getting in your way and obscuring the echo
area.

Btw, this all is in "emacs -Q", right?  There are no customizations
involved, right?

> The following is an IMO meaningless backtrace after hitting F10 the
> second time:

I think you are right.

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

I don't believe it can.