From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jared Finder via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: mouse-face and help echo support for xterm mouse Date: Thu, 05 Nov 2020 11:58:09 -0800 Message-ID: <946d9ea094642758037d1881a97e8d0c@finder.org> References: Reply-To: Jared Finder Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7831"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Roundcube Webmail/1.3.15 Cc: "Jared Finder via \"Emacs development discussions.\"" To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 05 20:59:14 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 1kalPd-0001u9-8B for ged-emacs-devel@m.gmane-mx.org; Thu, 05 Nov 2020 20:59:13 +0100 Original-Received: from localhost ([::1]:52354 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kalPc-0005lf-Ac for ged-emacs-devel@m.gmane-mx.org; Thu, 05 Nov 2020 14:59:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36028) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kalOg-00057M-E0 for emacs-devel@gnu.org; Thu, 05 Nov 2020 14:58:14 -0500 Original-Received: from greenhill.hpalace.com ([2600:3c01::f03c:91ff:fe73:2daa]:58040) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kalOe-0003gC-Ei for emacs-devel@gnu.org; Thu, 05 Nov 2020 14:58:14 -0500 Original-Received: from mail.finder.org (greenhill.hpalace.com [IPv6:2600:3c01::f03c:91ff:fe73:2daa]) by greenhill.hpalace.com (Postfix) with ESMTPSA id 5897B6C6; Thu, 5 Nov 2020 19:58:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=finder.org; s=2018; t=1604606290; bh=2SqSg36CfCSM5fuNbWnlaAjkdjCUsjNAgR+kT0AeFSo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=pkAqt4nl8tQUPyXka1H/DsGv/LWo3BcIkaftUgt1H6O8B4jyrwd8QUdau9D1VMQVj b4L28hTGWq0JZ1ot/gqgjjU1vua1a+DKqbEcsmLCFh1cpwZ6ayBmDg9UrexMQeOou8 R92OEQPfbV1KIvwLe/eCRgu6ZJn6QVWzUsgkOv6o3wamoLdG5XvS3xrbe/EHbftxZZ 80ZnuZESxbNGn+ujc8IM6i6NxxPyrGbRAhhyMDJHCxhHq4IwghrtJ7luh7Ix7Tuzly rHPd+CmYnM4BYfgZVBHwr+P/YAsT7ggiy2CCCQRgNBqGwOeM6/a7dFsUD5gAcnP5yO 266lNzZr294/g== In-Reply-To: X-Sender: jared@finder.org Received-SPF: pass client-ip=2600:3c01::f03c:91ff:fe73:2daa; envelope-from=jared@finder.org; helo=greenhill.hpalace.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: 12 X-Spam_score: 1.2 X-Spam_bar: + X-Spam_report: (1.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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:258755 Archived-At: On 2020-11-05 6:45 am, Stefan Monnier wrote: >> >> diff --git a/lisp/xt-mouse.el b/lisp/xt-mouse.el >> index f9c08f9a17..37550276f8 100644 >> --- a/lisp/xt-mouse.el >> +++ b/lisp/xt-mouse.el >> @@ -77,6 +77,7 @@ xterm-mouse-translate-1 >> (copy-sequence event)) >> vec) >> (is-move >> + (xterm-mouse--handle-mouse-motion) >> (if track-mouse vec >> ;; Mouse movement events are currently supposed to be >> ;; suppressed. Return no event. >> @@ -106,8 +107,16 @@ xterm-mouse-translate-1 >> (if (null track-mouse) >> (vector drag) >> (push drag unread-command-events) >> + (xterm-mouse--handle-mouse-motion) >> (vector (list 'mouse-movement ev-data)))))))))))) > > Hmm... `ev-data` includes the X/Y position, right? > Could we arrange to pass *that* data directly to > `xterm-mouse--handle-mouse-motion` rather than go through > (terminal-parameter frame 'xterm-mouse-x/y)? It likely won't make > much difference in practice, but it would make the data flow more > clear, > I think. Using ev-data's x,y would add significant complexity. ev-data is a posn, which is window part relative, not frame relative. >> +(defun xterm-mouse--handle-mouse-motion () >> + "Handle mouse motion that was just generated for XTerm mouse." >> + (let ((frame (selected-frame))) >> + (handle-lisp-mouse-motion frame >> + (terminal-parameter frame >> 'xterm-mouse-x) >> + (terminal-parameter frame >> 'xterm-mouse-y)))) > > This is the only caller to `handle-lisp-mouse-motion` and that function > has a "default frame to selected-frame" feature, so you could pass nil > instead of `frame`. Better yet, drop that frame argument altogether. > And I think the function's name should make it clear it's for internal > use only, or otherwise try to use some prefix that indicates it's > related to the display. Like `display-update-for-mouse-motion`? Is there a way I can name it that makes it clear this is an internal function and we may change the arguments in the future? I was hoping that this function would work with background frames across different TTYs in case I can figure out how to get that working. > [ I'm reminded here of the tension between using "mouse-motion" because > it's > shorter and using "mouse-movement" because that's the name of the > event. ] I squared this circle by using "mouse motion" for the concept and "mouse movement" for the event. I could rename to mouse-movement if you'd prefer. >> +This function should be called when Lisp code detects the mouse has >> +moved, even if `track-mouse' is nil. This handles updates that do >> not >> +not rely on input events such as updating display for mouse-face > > "not not" Done. >> +proprties or updating the help echo text. */) > ^^ > e Done. >> + (Lisp_Object frame, Lisp_Object mouse_x, Lisp_Object mouse_y) >> +{ >> + if (NILP (frame)) >> + frame = selected_frame; >> + >> + update_mouse_position (XFRAME (frame), XFIXNUM (mouse_x), XFIXNUM >> (mouse_y)); >> + return Qnil; >> +} > > This will crash and burn if `frame` is an integer (and the XFIXNUM > won't > crash and burn but they should also be preceded by CHECK_FIXNUMs). Done. >> if (event->type & (GPM_MOVE | GPM_DRAG)) >> { > [...] >> + /* Has the mouse moved off the glyph it was on at the last >> sighting? */ >> + if (event->x != last_mouse_x || event->y != last_mouse_y) >> + { >> + last_mouse_x = event->x; >> + last_mouse_y = event->y; >> + f->mouse_moved = 1; > > Would it make sense to try and add this test to the "generic" part of > the code? This is not possible without much further work. These are all tied with the C mouse event path: last_mouse_x, last_mouse_y, and frame.mouse_moved are all used by the mouse position hook and integrated with keyboard.c's mouse event generation. Making this shared would require changing the way xterm-mouse currently reports all mouse events to not return data through input-decode-map and instead creating a Lisp interface to the C mouse event generation logic. I tried playing around with this locally and it did seem like there is a path to make it work, but it would be a much bigger effort. As there's no logic changes, I'll wait for my questions above to get addressed before sending an updated patch. -- MJF