Re: Making TTY menus more visual

[Eli Zaretskii]

> Date: Fri, 02 Oct 2020 17:16:55 -0700
> From: Jared Finder <jared@finder.org>
> Cc: emacs-devel@gnu.org
> 
> This is for xterm-mouse support. From what I can tell, <menu-bar> 
> <mouse-1> is always bound to tmm-menubar. The following holds on Mac, 
> Windows, and Linux, and appears to be independent of if you start with 
> or without --no-window-system:
> 
> ELISP> (lookup-key global-map (kbd "<menu-bar> <mouse-1>"))
> tmm-menubar-mouse

That is true, but when mouse clicks on the menu bar are supported,
this binding is never used.  However, maybe this is not so for
xterm-mouse.

> This addition is for TTY menus triggered via xterm-mouse-mode. If this 
> makes sense to add as a feature, I can finish up my patches.

Yes, having the TTY drop-down menus supported with xterm-mouse is
something we would welcome very much.

> I see the following things that need to change:
> 
> 1. Add a new command that calls menu-bar-open with the right value for 
> initial-x. (this is the patch 001 in the root of the thread)

But patch 001 also includes unrelated parts, the tmm-menubar-item-at-x
function etc., right?

> 2. In read_menu_input in term.c, additional logic needs to be added to 
> handle xterm mouse clicks since the focused menu item will not be 
> necessarily the one clicked on.

I'm not sure I understand how this can happen.  Can you describe the
sequence of events that could lead to this, assuming tmm-menubar is
NOT involved?  When TTY menus drop down from the menu bar, the focused
item and the one clicked on should always coincide.  Any click on
another item is a click "outside of the popped up menu", and that
should dismiss the menu.

> Also, a user may click outside of the popped up menu, which they
> would expect to dismiss the menu. (this is patch 002 in the root of
> the thread, not yet complete)

This should already work; it does in the MS-Windows build when Emacs
is invoked with -nw.  Please tell more why you think any changes there
are needed.  Perhaps you could take me through the code there and
explain what is missing and why.  (And why do you call posn-x-y in the
patch when X and Y are already known and used by that code? is that
because mouse_get_xy does not yet support xterm-mouse? if so, that
support should be added via the terminal's mouse_position_hook.)

> 3. The new command should replace the current binding of <menu-bar> 
> <mouse-1>.

Yes, eventually this should be done as part of turning on
xterm-mouse-mode.

Thanks.