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 "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Mon, 25 Mar 2024 14:53:15 -0700 Message-ID: <11a3b53941f179d5e9b5d283f05c12be@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="8356"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 69915@debbugs.gnu.org, eliz@gnu.org To: Olaf Rogalsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 25 22:54:29 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1rosGy-00020f-9g for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 25 Mar 2024 22:54:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rosGc-0000m6-Bf; Mon, 25 Mar 2024 17:54:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rosGZ-0000lx-UX for bug-gnu-emacs@gnu.org; Mon, 25 Mar 2024 17:54:04 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rosGZ-0000Kx-GF for bug-gnu-emacs@gnu.org; Mon, 25 Mar 2024 17:54:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rosGY-0002dn-7O for bug-gnu-emacs@gnu.org; Mon, 25 Mar 2024 17:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jared Finder Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 25 Mar 2024 21:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69915 X-GNU-PR-Package: emacs Original-Received: via spool by 69915-submit@debbugs.gnu.org id=B69915.171140360110103 (code B ref 69915); Mon, 25 Mar 2024 21:54:02 +0000 Original-Received: (at 69915) by debbugs.gnu.org; 25 Mar 2024 21:53:21 +0000 Original-Received: from localhost ([127.0.0.1]:36453 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rosFr-0002cr-DP for submit@debbugs.gnu.org; Mon, 25 Mar 2024 17:53:20 -0400 Original-Received: from greenhill.hpalace.com ([192.155.80.58]:51150) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rosFo-0002cf-7e for 69915@debbugs.gnu.org; Mon, 25 Mar 2024 17:53:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=finder.org; s=2018; t=1711403595; bh=Ryi9bku00uk8c4d18P2CKGUUZg+gwiDDdzn0eIcF3js=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=xNGN3KDCLlHEcUg0PzcuanGpkETF73TSyYMSp32QtL8hF8DV9YqFi/SaSpDceDzHC 6ECIgzqGtx7tlemxklbgkJmnxIDb5Qx9xfTYS+oywyKeXoKu45XsI/2l1Dcah6EDwR ADm2g6DoAI3XEZ28MsI7rcq61pTPzoI5kQlLnE5Z09JHcrt9TYDVc5LqLlYeUYacA9 g84zkfNrgnMTUaEEANU8euwesPXKsFSnXqe209eqSqBQjlyvgSuveDLmbDPG4jszGM B+wmqnsQm4ADa68qAoioUcqDL/9eyUeGM9xPY8qxQG+OQ6neX3dbYLrmtuUMrCAcc/ 2mipw46RIVzsw== Original-Received: from mail.finder.org (unknown [192.155.80.58]) by greenhill.hpalace.com (Postfix) with ESMTPSA id C04FB9C1; Mon, 25 Mar 2024 21:53:15 +0000 (UTC) In-Reply-To: X-Sender: jared@finder.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:282078 Archived-At: On 2024-03-24 12:27, Olaf Rogalsky wrote: > Hi Jared, > > thanks for your feedback (answering this from my gmail account and > hope this doesn't mess up the debbugs history). > >> Are you certain you need the change to window.el as well? I'd be very >> surprised if it is necessary to change > ... >> Is your setup is different somehow? > No, but I forgot to mention, that the "nil is > undefined" error > only occurred, iff mouse-autoselect-window had a numeric value. > With my new patch, the error disappeared. I don't know why, but a > change to window.el > isn't necessary anymore. I still think, that the proposed change would > be correct. I'll defer to Eli here, but my general sentiment would be to leave window.el untouched unless a change is needed. The event list returned was last changed in 2006 so it's reasonably stable. >> events shouldn't be generated while the mouse is being >> dragged. This probably is reflected in fully by track-mouse, but I'd >> suggest looking at the native code that generates the event to >> confirm. > Truly understanding xterm.c unfortunately is beyond my expertise. > Nevertheless I > tested, the behavior. Dragging the mouse from one window to the next > (while passing over > the modeline) gives the following sequence of events: > > ESC [ < 3 5 ; 5 5 ; 4 1 M ESC [ < 0 ; 5 5 ; 4 1 M ;; mouse-drag-region > ESC [ < 3 2 ; 5 5 ; 4 2 M ;; anonymous-command > ESC [ < 3 2 ; 5 5 ; 4 3 M ;; anonymous-command > ESC [ < 3 2 ; 5 5 ; 4 4 M ;; ignore > ESC [ < 3 2 ; 5 6 ; 4 4 M ;; anonymous-command > ESC [ < 0 ; 5 6 ; 4 4 m ;; anonymous-command > ;; mouse-set-region > > So indeed, no select-window event is generated. As a result, dragging > the mouse over the > borders of the window results in a scrolling of the window. This > matches the behavior of the > X11 backend. Thank you. There's one remaining difference to handle that I highlight in the diff below. >> If there is a case where two events should be generated (not sure if >> this case exists depending on above), we'd want to return both, but >> you >> can only return a single key sequence from the translate function. I >> think this case deserves a FIXME note. > Can't follow you here. At which occasion two events might be generated > and which ones? I was thinking that if both a mouse movement and select window event should both be returned, like if track-mouse is non-nil and you switch windows. Can you test this case? >> Did you try out switching frames? I'm not certain if >> is >> supposed to be generated when the frame is switched. > Switching frames is not handled in xt-mouse.el. However, if you change > the focus from another > X11 window to the title bar of the terminal or wise-versa, no > switch-frame event is generated. Instead, > xterm-translate-focus-in/xterm-translate-focus-out are called via a > binding in xterm-rxvt-function-map. > These functions toggle the terminal parameter tty-focus-state between > focused and defocused and then > call after-focus-change-function, which also does not generate a > switch-frame event. > As far as I could find out, the X11 backend of emacs doesn't generate > switch-frame events, either. I was actually referring to using C-x 5 2 and C-x 5 o within a single terminal. I tested this locally and it works fine. > New patch: > ... other parts of patch look good to me :) ... > @@ -84,10 +89,19 @@ xterm-mouse-translate-1 > vec) > (is-move > (xterm-mouse--handle-mouse-movement) > - (if track-mouse vec > - ;; Mouse movement events are currently supposed to be > - ;; suppressed. Return no event. > - [])) > + (if (and mouse-autoselect-window ; after mouse movement Style nit: Can you please do this as a cond instead of a nested (if x y (if z u v))? > autoselect the mouse window, but ... > + (windowp ev-window) ; ignore modeline, tab-bar, > menu-bar and so forth ... > + ;;(not (posn-area (event-start event))) ; also > ignore, if not inside of text area of window ... > + (not (eq ev-window last-window)) ; but only, if mouse > is over new window ... > + (not (eq ev-window (selected-window)))) ; which is > different from the selected window Looking at xterm.c, I think you also want a test against window-minibuffer-p. > + (progn > + (put 'select-window 'event-kind 'switch-frame) > + (setf (car event) 'select-window) > + vec) I think this should be an event that's just select-window and the window, to line up with what the select-window event looks like on other platforms (I tested PGTK and Windows terminal). You can verify this by running M-x trace-function RET handle-select-window RET. That would instead be something like: (progn (put 'select-window 'event-kind 'switch-frame) (vector `(select-window (,ev-window))) Thank you so much for making this patch! -- MJF