bug#17497: 24.4.50; TTY menu glitches

[Eli Zaretskii <eliz@gnu.org>]

On the hunch that the problems discussed here are caused by excess
movement of the cursor, I've made changes in revision 117203 on the
emacs-24 branch to avoid some of them.  Please try that.

If the problems are still there, one last idea I have is to ifdef away
the code in tty_menu_activate that invokes the help-echo display:

      /* Display the help-echo message for the currently-selected menu
	 item.  */
      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);
	  /* Move the cursor to the beginning of the current menu
	     item, so that screen readers and other accessibility aids
	     know where the active region is.  */
	  cursor_to (sf, row, col);
	  prev_menu_help_message = menu_help_message;
	}

This code invokes another update of the frame, in addition to the one
we already did when we called tty_menu_display immediately before
that.  It also moves the cursor (which is positioned by the frame
update to where point is in the selected window).  Maybe avoiding that
will avoid the problems.

If even that doesn't help, then try to ifdef away the calls to
tty_hide_cursor made by tty_menu_activate.

These two last ideas are the only differences I know of between a
"normal" redisplay and redisplay due to update of a menu.  If even
they don't make any difference, I guess this bug will have to remain
open until someone debugs it on a system where the problem can be
reproduced.