Re: commands invoked by the mouse -> commands invoked from the menu bar

[Jason Rumney]

Jason Rumney <address@hidden> writes:

> Perhaps menu events are being saved in last_nonmenu_event, at
> least on Windows.

In keyboard.c, I see the following comment. So the menu-bar event
seems to be deliberately saved in last_nonmenu_event on all toolkit
based builds.

#if defined (USE_X_TOOLKIT) || defined (HAVE_NTGUI) || defined(MAC_OS) \
    || defined (USE_GTK)
              /* If this was a menu selection, then set the flag to inhibit
                 writing to last_nonmenu_event.  Don't do this if the event
                 we're returning is (menu-bar), though; that indicates the
                 beginning of the menu sequence, and we might as well leave
                 that as the `event with parameters' for this selection.  */

Although the comment says "we might as well leave that", it is
actually quite important that we leave it on Windows and possibly with
some or all of the other toolkits listed, since we do not see any
events that are processed by the menu bar, including the mouse event
that started the sequence.

ie. Using the mouse to select the open-file menu item, view-lossage
    reports: <menu-bar> <file> <open-file>

    Using F10 and arrow keys to select the same menu item,
    view-lossage reports: <f10> <menu-bar> <file> <open-file>


So unless we look at the event before the menu-bar event and check its
binding (which may involve prior events - how do we tell when working
backwards?) to see if it might have caused the menu to open, we cannot
tell whether the mouse or keyboard was used.