Re: Making TTY menus more visual

[Eli Zaretskii]

> Date: Sat, 03 Oct 2020 15:28:23 -0700
> From: Jared Finder <jared@finder.org>
> Cc: emacs-devel@gnu.org
> 
> It wasn't that much more work to get xterm-mouse to work. I've attached 
> an updated patch.

See some comments below.

> 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 "<mode-line> <mouse-movement>" or "<vertical-line> 
> <mouse-movement>". 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.

Emacs normally doesn't receive mouse-movement events unless we
explicitly enable that, see the macro track-mouse.  And the
menu-processing code for other TTYs doesn't enable mouse-movement
events because it isn't needed: with other mice the mouse coordinates
can be read even if the button wasn't clicked.  Isn't there a similar
feature of xterm, whereby we can send some command to the mouse driver
to respond with the current mouse coordinates?  If so, it would be a
better match for what other mice do.  But if such a command doesn't
exist for xterm, we will need to enable mouse-movement events for menu
processing by xterm-mouse.  If that requires binding more key
combinations to 'ignore', I see no problem with that, as other mouse
interfaces don't care.

> diff --git a/lisp/xt-mouse.el b/lisp/xt-mouse.el
> index 362d29b943..ae6f85f1f7 100644
> --- a/lisp/xt-mouse.el
> +++ b/lisp/xt-mouse.el
> @@ -339,7 +339,7 @@ xterm-mouse-tracking-enable-sequence
>              position (<= 223), which can be reported in this
>              basic mode.
>  
> -\"\\e[?1002h\" \"Mouse motion mode\": Enables reports for mouse
> +\"\\e[?1003h\" \"Mouse motion mode\": Enables reports for mouse
>              motion events during dragging operations.

I think we should only switch to 0x1003 when the track-mouse variable
is non-nil, see the macro track-mouse and its internal part
internal--track-mouse.

> @@ -2804,16 +2814,14 @@ tty_menu_calc_size (tty_menu *menu, int *width, int 
> *height)
>  static void
>  mouse_get_xy (int *x, int *y)
>  {
> -  struct frame *sf = SELECTED_FRAME ();
> -  Lisp_Object lmx = Qnil, lmy = Qnil, lisp_dummy;
> -  enum scroll_bar_part part_dummy;
> -  Time time_dummy;
> -
> -  if (FRAME_TERMINAL (sf)->mouse_position_hook)
> -    (*FRAME_TERMINAL (sf)->mouse_position_hook) (&sf, -1,
> -                                                 &lisp_dummy, &part_dummy,
> -                                              &lmx, &lmy,
> -                                              &time_dummy);
> +  Lisp_Object lmx = Qnil, lmy = Qnil, mouse_position = Fmouse_position ();
> +
> +  if (EQ (selected_frame, XCAR(mouse_position)))
> +    {
> +      lmx = XCAR (XCDR (mouse_position));
> +      lmy = XCDR (XCDR (mouse_position));
> +    }
> +

This is okay as a general idea, but it would be more clean to make
Fmouse_position call a new C function (extracted from the first part
of Fmouse_position's code) that just computes the mouse coordinates.
Then Fmouse_position's would call mouse-position-function after the
new C function returns.  Then in term.c we could call just that new C
function.  This is because it is inappropriate for mouse_get_xy to
call mouse-position-function when a menu is being processed.

Thanks.