From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Making TTY menus more visual Date: Sun, 04 Oct 2020 09:43:12 +0300 Message-ID: <838scmfq4f.fsf@gnu.org> References: <087df85a965fac6555a755c1bbebf1ea@finder.org> <83r1qhf5ii.fsf@gnu.org> <83wo07g0bf.fsf@gnu.org> <85afa5c0a0a789c6047e92f6ecfa9fcc@finder.org> <72bbff31bcf46be917c9e8d8236cad75@finder.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14286"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Jared Finder Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Oct 04 08:44:13 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kOxki-0003cp-Fs for ged-emacs-devel@m.gmane-mx.org; Sun, 04 Oct 2020 08:44:12 +0200 Original-Received: from localhost ([::1]:60864 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kOxkh-0004Qp-GY for ged-emacs-devel@m.gmane-mx.org; Sun, 04 Oct 2020 02:44:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47222) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kOxjo-0003z0-Kf for emacs-devel@gnu.org; Sun, 04 Oct 2020 02:43:16 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37354) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kOxjo-0002mL-5z; Sun, 04 Oct 2020 02:43:16 -0400 Original-Received: from [176.228.60.248] (port=4681 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kOxjn-0000KV-GG; Sun, 04 Oct 2020 02:43:15 -0400 In-Reply-To: <72bbff31bcf46be917c9e8d8236cad75@finder.org> (message from Jared Finder on Sat, 03 Oct 2020 15:28:23 -0700) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:257011 Archived-At: > Date: Sat, 03 Oct 2020 15:28:23 -0700 > From: Jared Finder > 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 " " 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. 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.