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: Wed, 27 Mar 2024 14:47:27 -0700 Message-ID: References: <87zfutaram.fsf@t-online.de> 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="19307"; 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 Wed Mar 27 22:48:16 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 1rpb83-0004p3-VF for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 27 Mar 2024 22:48:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rpb7r-000486-Lb; Wed, 27 Mar 2024 17:48:03 -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 1rpb7q-00047y-DY for bug-gnu-emacs@gnu.org; Wed, 27 Mar 2024 17:48:02 -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 1rpb7q-0000qd-5l for bug-gnu-emacs@gnu.org; Wed, 27 Mar 2024 17:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rpb7q-0007sV-Fo for bug-gnu-emacs@gnu.org; Wed, 27 Mar 2024 17:48:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <87zfutaram.fsf@t-online.de> Resent-From: Jared Finder Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 27 Mar 2024 21:48: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.171157605430016 (code B ref 69915); Wed, 27 Mar 2024 21:48:02 +0000 Original-Received: (at 69915) by debbugs.gnu.org; 27 Mar 2024 21:47:34 +0000 Original-Received: from localhost ([127.0.0.1]:38467 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rpb7L-0007nX-GH for submit@debbugs.gnu.org; Wed, 27 Mar 2024 17:47:34 -0400 Original-Received: from greenhill.hpalace.com ([192.155.80.58]:49712) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rpb7J-0007nA-0S for 69915@debbugs.gnu.org; Wed, 27 Mar 2024 17:47:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=finder.org; s=2018; t=1711576047; bh=i76/afDARrIIl01qH6vYOFDD381rtJqjlveEH0UwnVA=; h=Date:From:To:Cc:Subject:From; b=0t4bT5gOStocNsT8dA7TLbA1bAcHA+4BVAX3QM8pgRlAIRmUG+x69bcXm+totrFeF xMn82oG9P20ahO0zc84vp7CTa62zceztJEoSP3cfrlfUhpJMkn2YCJEJhmUvM0AUg5 Q0+BVv510xx+Ax477BtaLGgWXKjV+aQ4TAhWNfTg+F/aQJB0wJLRDjPnrVylp2JU4J 0qYbkwiqANq7uUbtm0V0gXIcYnWXGM1bZwMFTL69aEQbPrWd3uV/Cgurd4eNYDh/5+ Ya9KyKbB1MlPOi1flR8xvz+o82lfXr3VpC+fYvjCPDcWDEDiBZYYQf5oxQlVslv8JV +9wwQOnCUlVXw== Original-Received: from mail.finder.org (unknown [192.155.80.58]) by greenhill.hpalace.com (Postfix) with ESMTPSA id 8F7A960A; Wed, 27 Mar 2024 21:47:27 +0000 (UTC) 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:282160 Archived-At: On 2024-03-26 16:50, Olaf Rogalsky wrote: > Hi Jared, > >> >> 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: ... elided comments ... >> > 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? > > Test case 1: > (track-mouse > (setq mouse-autoselect-window t) > > (let (e) > (while (not (eq e ?q)) > (setq e (read-key)) > (when (and (consp e) (symbolp (car e))) > (message "%s to %s at posn %s" (car e) (caadr e) (posn-x-y > (cadr e))))))) > > Result with patched terminal: ... elided results ... > > For the second test case I use read-key-sequence instead of read-key > > Test case 2: > > (track-mouse > (let ((can-return-switch-frame t) e) > (while (not (equal e "q")) > (setq e (read-key-sequence nil nil t can-return-switch-frame > nil)) > (when (not (stringp e)) > (setq e (seq-elt e 0)) > (message "%s to %s at posn %s" (car e) (caadr e) (posn-x-y > (cadr e))))))) > > Result with patched terminal: ... elided results ... > > So, read-key behaves differently in the terminal compared to X11: > In the terminal, the can-return-switch-frame parameter of > read-key-sequence > has no effect and select-window events are always generated. > > Fyi, the can-return-switch-frame parameter is handled at +10838 > keyboard.c > in the monstrous over 1000 lines long function read_key_sequence: > > if (EVENT_HAS_PARAMETERS (key) > /* Either a `switch-frame' or a `select-window' event. */ > && EQ (EVENT_HEAD_KIND (EVENT_HEAD (key)), Qswitch_frame)) > { > /* If we're at the beginning of a key sequence, and the caller > says it's okay, go ahead and return this event. If we're > in the midst of a key sequence, delay it until the end. */ > if (t > 0 || !can_return_switch_frame) > { > delayed_switch_frame = key; > goto replay_key; > } > } > But apparently these lines are never executed in the case of the > terminal input. Sadly, read_key_sequence in C code is quite a beast. One last experiment is worth trying here. If this doesn't work out, I think a FIXME will be sufficient. Instead of returning the event, try pushing the event onto unread-command-events. My thought is that this will let native code dequeue and handle the event normally, including taking can_return_switch_frame into account. Can you please try this? >> > 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. > > On the other hand, looking at msdos.c, there is no test against the > minibuffer. I believed, that > the selection of the minibuffer is taken care of at +10638 of > window.el. In my tests the patch > behaves exactly like the documentation, quote: "Mouse auto-selection > selects the minibuffer window > only if it is active, and never deselects the active minibuffer > window." > I added the test, but commented it out. I'm not sure what the right way to proceed here is then. Eli, can you give advice? Looking at different OS files that handle mouse_autoselect_window, I see the following state for checks if the selected window is a minibuffer with MINI_WINDOW_P: pgtkterm.c: checks w32term.c: does NOT check w32inevt.c: does NOT check nsterm.m: checks xterm.c: checks msdos.c: does NOT check haikuterm.c: checks androidterm.c: checks term.c: no support for mouse-autoselect-window. :( My gut is to assume that the X and GTK behavior is most likely to be better tested and more correct, but I defer to Eli here. > I also commented out a condition, which ensures that the selection of a > window can only occur, if the mouse is in the text area of the window. > This matches the following sentence of the documentation: > "In either case, the mouse pointer must enter the text area of a window > in order to trigger its selection." > But I found no situation, where it did matter and msdos.c didn't have > that test, either. WDYT? I think the documentation is incorrect and this commented out case should be removed. Local testing on PGTK and Mac shows that the mouse pointer can be over the window dividers, widget scroll bars, or fringes and still have autoselect behavior activate. >> > + (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))) > > I can't find the documentation of the format of the select-window > event. Maybe its a good idea to add it. Agreed. I think it should be added to Focus Events in commands.texi. > Please find below the next iteration of the patch. Assuming above comments are addressed, this looks good to me. I imagine there will be minor comment reformatting to avoid going beyond 80 columns. > diff --git a/lisp/xt-mouse.el b/lisp/xt-mouse.el > index 081b8f32456..88c6c28b293 100644 > --- a/lisp/xt-mouse.el > +++ b/lisp/xt-mouse.el > @@ -60,7 +60,9 @@ xterm-mouse-translate-1 > (let* ((event (xterm-mouse-event extension)) > (ev-command (nth 0 event)) > (ev-data (nth 1 event)) > + (ev-window (nth 0 ev-data)) > (ev-where (nth 1 ev-data)) > + (last-window (terminal-parameter nil > 'xterm-mouse-last-window)) > (vec (vector event)) > (is-move (eq 'mouse-movement ev-command)) > (is-down (string-match "down-" (symbol-name ev-command)))) > @@ -73,6 +75,9 @@ xterm-mouse-translate-1 > 'mouse-movement > 'mouse-click))) > > + ;; remember window of current mouse position > + (set-terminal-parameter nil 'xterm-mouse-last-window ev-window) > + > (cond > ((null event) nil) ;Unknown/bogus byte sequence! > (is-down > @@ -84,10 +89,16 @@ 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. > - [])) > + (cond ((and mouse-autoselect-window ; after mouse movement > 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 (window-minibuffer-p (selected-window))) ; > and don't deselect the minibuffer > + (not (eq ev-window last-window)) ; and select > only, if mouse is over a new window ... > + (not (eq ev-window (selected-window)))) ; which is > different from the selected window > + (put 'select-window 'event-kind 'switch-frame) > + (vector `(select-window (,ev-window)))) > + (track-mouse vec) > + (t []))) > (t > (let* ((down (terminal-parameter nil 'xterm-mouse-last-down)) > (down-data (nth 1 down))