emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Menus with more items than the TTY can display


From: Eli Zaretskii
Subject: Re: Menus with more items than the TTY can display
Date: Thu, 17 Oct 2013 19:38:57 +0300

> Date: Thu, 17 Oct 2013 11:28:47 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden, address@hidden
> 
> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]