From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Olaf Rogalsky Newsgroups: gmane.emacs.bugs Subject: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Sat, 30 Mar 2024 18:03:37 +0100 Message-ID: <87ttkny7gp.fsf@gmail.com> References: <86v856hon0.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9378"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.9.11; emacs 30.0.50 Cc: 69915@debbugs.gnu.org, Jared Finder To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Mar 30 18:08:24 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 1rqcBs-0002DZ-9O for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Mar 2024 18:08:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rqcBW-00085O-BT; Sat, 30 Mar 2024 13:08:02 -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 1rqcBU-0007yi-Lp for bug-gnu-emacs@gnu.org; Sat, 30 Mar 2024 13:08:00 -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 1rqcBU-0005Je-BX for bug-gnu-emacs@gnu.org; Sat, 30 Mar 2024 13:08:00 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rqcBW-0002kh-02 for bug-gnu-emacs@gnu.org; Sat, 30 Mar 2024 13:08:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Olaf Rogalsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Mar 2024 17:08:01 +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.171181843610478 (code B ref 69915); Sat, 30 Mar 2024 17:08:01 +0000 Original-Received: (at 69915) by debbugs.gnu.org; 30 Mar 2024 17:07:16 +0000 Original-Received: from localhost ([127.0.0.1]:46123 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqcAl-0002iu-Sq for submit@debbugs.gnu.org; Sat, 30 Mar 2024 13:07:16 -0400 Original-Received: from mail-wm1-x331.google.com ([2a00:1450:4864:20::331]:58372) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqcAi-0002i3-Fk for 69915@debbugs.gnu.org; Sat, 30 Mar 2024 13:07:14 -0400 Original-Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-4154471fb81so17640315e9.0 for <69915@debbugs.gnu.org>; Sat, 30 Mar 2024 10:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711818424; x=1712423224; darn=debbugs.gnu.org; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:from:to:cc:subject:date:message-id:reply-to; bh=wikve3owC+6MsU944FLoz9rGd34/xJbKs1jEVlj7mps=; b=IxQfKZiD+pZX0g8jFQkH2Hdi6SfSg+6m5Hdvf26Gmd6LGmLZjkxVYDBxvlHrtnuyqY gWc5NZHz+KPah/hmt6WLF7JVEQV70Rz/bQIHDmbJgw6mPVpP35K9+JqKQG6WM+3fbEbU u3okYj88JWp0vuWHHFf1ZEduj/YuobywmBCF9BLYVONPuYrA98a+xiOJ3t6LTPkScjTW auvDnPP/2iLHsydPp1T48M4xi2zXTmCNB1ruW2WDuu6ncs2JJdnyq8Vr2JbhrrIl73S9 /8GE6WoJn7jw6bqf5jcVnCZYQvUynsNr0gfLoT1oOPLkeV24by38DJOvFl0GFdhis7Qc XG+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711818424; x=1712423224; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=wikve3owC+6MsU944FLoz9rGd34/xJbKs1jEVlj7mps=; b=umMU72QHGp4ykSC2RvN9Mn8TSw/yE1LWp5ly4Uyegofo/+8pUspscE9IgUXlbHFIeY 0IdFrddEyfJxZDH3F7/igx4Plt9Brw+TCGxoAL6DvfvaSrKEUWqwF5DqG0wzvl62d1jY ++Or43ks+tAdiaa481DN7pqMVPz/4+FjyTq6sbTMBxASdEjiqg1IDE0H+wCPG4mzELbq VDXWJyMA4SqkwS9Ps8GZMpKsYQuhw7anHUqZZ1mc5dftTLDYes+dp7vy9QSBRpgBRLUE ozT1nT1sWlWrmh5E/SYZ+pW+IGrjkJfseTQbLmLQMz9UtpN9PlH3K9F8TmEhKmPRI3z4 sBTg== X-Forwarded-Encrypted: i=1; AJvYcCVt3hYU4dn/2h1sMoruw7B2bW8+Ob+sN4V2RvfYdULCydgic/8fudsSI+9YQdKMrpG7Z6SO6x/bD/rFcMLrWASzxKjQjBY= X-Gm-Message-State: AOJu0YzdXUyGrVh6ALXB3flG4MybsbvpPZRrhjk224GXJf8gfk89Ro6Q SgRTLh1rorTnPw7ZWfiEKPRVGU9hCjHo4pZWe2bhFJH9YZNBKDt1NE3RPs22+v0= X-Google-Smtp-Source: AGHT+IGIIMH7/WtxSxNKBszFBo1nBiZbpolIyyVnG0EFl6K6GAVQ2rpr602YcJhr+H2wQr3NBBfVIw== X-Received: by 2002:adf:e052:0:b0:341:be5f:ff21 with SMTP id w18-20020adfe052000000b00341be5fff21mr3544516wrh.55.1711818424189; Sat, 30 Mar 2024 10:07:04 -0700 (PDT) Original-Received: from blaubaer ([2a02:8070:d283:5000:e9ff:6c98:9df:2a12]) by smtp.gmail.com with ESMTPSA id dp18-20020a0560000c9200b00341de138a2esm6856800wrb.94.2024.03.30.10.07.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 30 Mar 2024 10:07:03 -0700 (PDT) In-reply-to: <86v856hon0.fsf@gnu.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:282389 Archived-At: --=-=-= Content-Type: text/plain Hi Jared and Eli, Jared Finder writes: > 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 ... >> But apparently these lines are never executed in the case of the >> terminal input. ... > 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? Good idea, this solved the inconsistency. > Looking at xterm.c, I think you also want a test against > window-minibuffer-p. ... > 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 tend to agree. But, just to be sure, can you or Olaf describe the >> exact issue and how it could happen, and perhaps show a recipe to try >> reproducing it? I'd like to take a closer look at the relevant code. Jared alreaddy answered your question. I added the test against the minibuffer, like xterm.c and pgtkterm.c do. >>> 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. > Is this at all relevant for TTY frames? Everything is "text area" on > TTY frames, right? If not, what are the use cases where the mouse > would be "not in the text area" on a TTY frame, in the context of > auto-selecting a window? I interpreted the phrase "text area" as those parts of the frame, which show the contents of buffers, i.e. without modeline, window separators, tab-bar, menu-bar. In other words, anything where posn-area returns nil. Nevertheless, since no other backend checks for the text area, I removed the out-commented test. >> 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. But probaly by someone who knows the texi format and has a better command of the english language than I do. Sorry. Olaf PS: sorry for the horrible formatting of the previous messages: I usually do not use my gmail account ... Hope, this one comes out better. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Fix-user-option-mouse-autoselect-window-for-tty-emac.patch >From 8de818075ff5e583e25d4f408b9333fac2c37a3c Mon Sep 17 00:00:00 2001 From: Olaf Rogalsky Date: Sat, 30 Mar 2024 17:00:51 +0100 Subject: [PATCH] Fix user option mouse-autoselect-window for tty emacs Generate select-window events, so that mouse-autoselect-window takes effect in tty emacs, when xterm-mouse-mode is enabled (Bug#69915). * lisp/xt-mouse.el (xterm-mouse-translate-1): If mouse-autoselect-window is non-nil, add select-window events to unread-command-events. --- lisp/xt-mouse.el | 25 +++++++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-) diff --git a/lisp/xt-mouse.el b/lisp/xt-mouse.el index 081b8f32456..783718b4ba4 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,22 @@ 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. - [])) + ;; after mouse movement autoselect the mouse window, but ... + (cond ((and mouse-autoselect-window + ;; ignore modeline, tab-bar, menu-bar and so forth ... + (windowp ev-window) + ;; and don't deselect the minibuffer ... + (not (window-minibuffer-p (selected-window))) + ;; and select only, if mouse is over a new window ... + (not (eq ev-window last-window)) + ;; which is different from the selected window + (not (eq ev-window (selected-window)))) + (put 'select-window 'event-kind 'switch-frame) + (push `(select-window (,ev-window)) unread-command-events) + []) + ;;(vector `(select-window (,ev-window)))) + (track-mouse vec) + (t []))) (t (let* ((down (terminal-parameter nil 'xterm-mouse-last-down)) (down-data (nth 1 down)) --=-=-=--