Re: Making TTY menus more visual

[Jared Finder]

On 2020-10-12 7:45 am, Eli Zaretskii wrote:
> > Date: Sun, 11 Oct 2020 20:25:13 -0700
> > From: Jared Finder <jared@finder.org>
> > Cc: emacs-devel@gnu.org
> >
> > -(defun menu-bar-open-mouse (event)
> > +(defun menu-bar-open-mouse (position)
> >    "Open the menu bar for the menu item clicked on by the mouse.
> > -EVENT should be a mouse down or click event.
> > +POSITION should be a list of the form returned by `mouse-position'.
> >
> >  Also see `menu-bar-open', which this calls.
> >  This command is to be used when you click the mouse in the menubar."
> > -  (interactive "e")
> > -  (let* ((x-position (car (posn-x-y (event-start event))))
> > +  (interactive (list (mouse-position)))
> > +  (let* ((x-position (cadr position))
>
> I'd prefer not to lose the "e" interactive spec and the form of the
> argument here.  If the problem is the conversion of window-relative to
> frame-relative coordinates, that is easy, and the ELisp manual has an
> example of how to do that in the node "Accessing Mouse".
>
> Or is there some problem to use this here?

Thanks, I investigated further and I have an improved patch attached.  
In addition to keeping the same interactive spec, it also is logically 
independent of my changes to enable xterm-mouse based menu interaction.  
I also attached repro.el, which I used to help understand the behavior 
of xterm-mouse.

The manual is not clear of the format of a posn for clicks outside a 
window, such as on the menu bar or tab bar. From the behavior I see, 
posn-window will return nil and posn-x-y will return (x . y) in frame 
coordinates. I rely on that in this patch. If this is accurate, I can 
update the manual.

  -- MJF

0001-Fixing-bug-where-the-wrong-menu-would-be-triggered-b.patch
Description: Text Data

repro.el
Description: Text Data