From: Eli Zaretskii <eliz@gnu.org>
To: Jared Finder <jared@finder.org>
Cc: emacs-devel@gnu.org
Subject: Re: Making TTY menus more visual
Date: Sun, 04 Oct 2020 09:43:12 +0300 [thread overview]
Message-ID: <838scmfq4f.fsf@gnu.org> (raw)
In-Reply-To: <72bbff31bcf46be917c9e8d8236cad75@finder.org> (message from Jared Finder on Sat, 03 Oct 2020 15:28:23 -0700)
> 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.
next prev parent reply other threads:[~2020-10-04 6:43 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-02 6:16 Making TTY menus more visual Jared Finder via Emacs development discussions.
2020-10-02 7:31 ` Eli Zaretskii
2020-10-03 0:16 ` Jared Finder via Emacs development discussions.
2020-10-03 8:50 ` Eli Zaretskii
2020-10-03 19:26 ` Jared Finder via Emacs development discussions.
2020-10-03 22:28 ` Jared Finder via Emacs development discussions.
2020-10-03 23:25 ` Jared Finder via Emacs development discussions.
2020-10-04 6:43 ` Eli Zaretskii [this message]
2020-10-04 9:04 ` Eli Zaretskii
2020-10-05 5:36 ` Jared Finder via Emacs development discussions.
2020-10-05 6:45 ` Eli Zaretskii
2020-10-08 6:39 ` Jared Finder via Emacs development discussions.
2020-10-08 8:15 ` Eli Zaretskii
2020-10-09 5:17 ` Jared Finder via Emacs development discussions.
2020-10-09 15:02 ` Eli Zaretskii
2020-10-10 5:20 ` Jared Finder via Emacs development discussions.
2020-10-10 7:28 ` Eli Zaretskii
2020-10-12 3:25 ` Jared Finder via Emacs development discussions.
2020-10-12 14:45 ` Eli Zaretskii
2020-10-12 21:30 ` Jared Finder via Emacs development discussions.
2020-10-13 14:33 ` Eli Zaretskii
2020-10-14 1:59 ` Jared Finder via Emacs development discussions.
2020-10-15 13:34 ` Eli Zaretskii
2020-10-16 6:51 ` Eli Zaretskii
2020-10-16 16:18 ` Jared Finder via Emacs development discussions.
2020-10-24 10:31 ` Eli Zaretskii
2020-10-25 0:27 ` Jared Finder via Emacs development discussions.
2020-10-31 8:05 ` Eli Zaretskii
2020-10-24 10:25 ` Eli Zaretskii
2020-10-04 6:22 ` Eli Zaretskii
2020-10-04 6:24 ` Eli Zaretskii
2020-10-04 22:15 ` Jared Finder via Emacs development discussions.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=838scmfq4f.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=jared@finder.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.