On 2020-10-03 12:26 pm, Jared Finder wrote: > On 2020-10-03 1:50 am, Eli Zaretskii wrote: >>> Date: Fri, 02 Oct 2020 17:16:55 -0700 >>> From: Jared Finder >>> Cc: emacs-devel@gnu.org >>> >>> 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.) > > From injecting debug logs into read_menu_input, I can observe that > tty-menu-mouse-movement is never received so the highlighted item > never changes except due to keyboard input. And from tracing > xterm-mouse--read-event-sequence, it appears that Emacs normally does > not receive xterm mouse motion events unless a button is pressed. > > This appears to be due to xt-mouse sending event code 1002 instead of > 1003 (see > https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Mouse-Tracking). > > Just sending 1003 instead doesn't just work, but I do see mouse events > now coming through. Let me do some more investigation here and I will > get back to you. It wasn't that much more work to get xterm-mouse to work. I've attached an updated patch. I have just one question, corresponding to the remaining TODO: Now there are newly emitted events for mouse-movement that are not handled such as " " or " ". It'd be easy enough to bind all of these to ignore and further update tty-menu-navigation-map to have more cases, but is that the right solution? I'm surprised that only xterm-mouse would run into this case. -- MJF