From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: mouse-face and help echo support for xterm mouse Date: Thu, 05 Nov 2020 09:45:46 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27996"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: "Jared Finder via \"Emacs development discussions.\"" To: Jared Finder Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 05 15:47:58 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 1kagYP-0007Ai-Jd for ged-emacs-devel@m.gmane-mx.org; Thu, 05 Nov 2020 15:47:57 +0100 Original-Received: from localhost ([::1]:43518 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kagYO-0001XT-Iy for ged-emacs-devel@m.gmane-mx.org; Thu, 05 Nov 2020 09:47:56 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47062) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kagWP-0000bv-99 for emacs-devel@gnu.org; Thu, 05 Nov 2020 09:45:53 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:22354) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kagWM-000289-OM for emacs-devel@gnu.org; Thu, 05 Nov 2020 09:45:52 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 81AAB809BF; Thu, 5 Nov 2020 09:45:49 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 4371980853; Thu, 5 Nov 2020 09:45:47 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1604587547; bh=INGsQvrz7ef9tJvkt//lnfQw4UshzP5chFS0cYOmUX4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=LcmK4gN1HyR+ne3ddqrN3I5G+jothYBFzqbEXnpMUr12jnBc1NRcebhcjxLvltF06 CtORfRNaAh1j0B0RA1RKiXOGY1m4DBqgyKVTGxKRunJtaYcTpS0Dc1EHdXwBocHLCY XX350CS1YkvYnbIRcCNItDlytUTX+WZzOdPrL0kVEdzamQWxCmMO+FHsTfsbNph0/a CNHfB+K9o487MNPgMoDxzXmjGmSV5UoJlnPg1m2ei9qkKrgKmR9wgQnLY/iqCms4LX 7Pje2fuXfwLyNgpF3mCaonBJ8rmbFf/IubvJYKRmXu6YlBg5TEqNFAELAYFG6vF6T0 pWxS6OA0zxLEw== Original-Received: from alfajor (unknown [157.52.9.240]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 1CE0C120455; Thu, 5 Nov 2020 09:45:47 -0500 (EST) In-Reply-To: (Jared Finder's message of "Thu, 05 Nov 2020 00:15:10 -0800") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/05 09:21:03 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:258726 Archived-At: > With the code simplification in, this logic is now sharable between > xterm-mouse and GPM. Attached is an updated patch. Thanks. > This patch does have one actual logic change: Previously > handle_one_term_event might call gen_help_event if a GPM_MOVE_EVENT or > GPM_DRAG_EVENT happened but the mouse position did not change. With this > patch, this is no longer the case. From testing locally with running GPM > mouse, this seems to not cause any user-visible change. I wouldn't worry about that, indeed. It's typically the kind of minor discrepancies that accrue when code is duplicated and which make merging them back "fun". You just have to choose which of the two behaviors is preferable and I think here the better choice is to refrain from generating an event when the position didn't actually change. Further comments below. Stefan > 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. > +(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`? [ 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. ] > +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" > +proprties or updating the help echo text. */) ^^ e > + (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). > 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? Stefan