bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

[Olaf Rogalsky]

Hi,

when using emacs in the terminal, the mouse-autoselect-window variable
has no effect, i.e. moving the mouse from one window to the next does
not change the selected window.

Recipe:
--- snip ---
emacs -nw
M-: (xterm-mouse-mode 1)
M-: (setq mouse-autoselect-window t)
C-x 2
<mouse-motion <<<other window>>> >
--- snap ---

The reason is, that xt-mouse.el does not generate <select-window>
events. The following patch fixes that.

To this end, it also fixes a bug in "window.el". Here, the
<select-window> event which is added to `last-input-event', does not
contain a propper posn field. In X11, this works fine, but in the
terminal it results in a "nil <select-window> is undefined" error.

Regards, Olaf


diff --git a/lisp/window.el b/lisp/window.el
index 246708dbd56..8af1cf485bd 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -10645,7 +10645,7 @@ mouse-autoselect-window-select
       ;; autoselection again, set `mouse-autoselect-window-state'."
       (setq mouse-autoselect-window-state 'select)
       (setq unread-command-events
-            (cons (list 'select-window (list window))
+            (cons (list 'select-window (posn-at-point nil window))
                   unread-command-events)))
      ((or (not (numberp mouse-autoselect-window))
           (equal mouse-position mouse-autoselect-window-position))
diff --git a/lisp/xt-mouse.el b/lisp/xt-mouse.el
index 081b8f32456..aaaffb3a534 100644
--- a/lisp/xt-mouse.el
+++ b/lisp/xt-mouse.el
@@ -42,6 +42,8 @@

 (require 'mwheel)

+(defvar last-mouse-window nil)
+
 (defvar xterm-mouse-debug-buffer nil)

 (defun xterm-mouse-translate (_event)
@@ -338,6 +340,15 @@ xterm-mouse-event
           (set-terminal-parameter nil 'xterm-mouse-last-click
                                   (list type this-time click-count x y)))

+        (when (and mouse-autoselect-window
+                   (mouse-movement-p event)
+                   (windowp w)
+                   (not (posn-area (event-start event))))
+          (when (and (not (eq w last-mouse-window))
+                     (not (eq w (selected-window))))
+            (setf (car event) 'select-window))
+          (setq last-mouse-window w))
+
         (set-terminal-parameter nil 'xterm-mouse-x x)
         (set-terminal-parameter nil 'xterm-mouse-y y)
         (setq last-input-event event)))))






In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.18.0) of 2024-01-22 built on blaubaer
Repository revision: 797c688f4ab33a196477fd85f83f7438d113dc7d
Repository branch: master
System Description: Manjaro Linux

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
 --with-modules --without-m17n-flt --without-gconf
 --with-native-compilation=yes --with-xinput2 --with-x-toolkit=gtk3
 --without-xaw3d --with-sound=no --with-tree-sitter --without-gpm
 --without-compress-install
 '--program-transform-name=s/\([ec]tags\)/\1.emacs/'
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
 -fno-plt' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PNG RSVG SECCOMP SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LC_COLLATE: C.UTF-8
  value of $LC_MONETARY: de_DE.UTF-8
  value of $LC_NUMERIC: de_DE.UTF-8
  value of $LC_TIME: de_DE.UTF-8
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: mu4e-headers

Minor modes in effect:
  mu4e-search-minor-mode: t
  hl-line-mode: t
  mu4e-update-minor-mode: t
  mu4e-context-minor-mode: t
  global-page-break-lines-mode: t
  openwith-mode: t
  winner-mode: t
  recentf-mode: t
  windmove-mode: t
  auto-compile-on-load-mode: t
  auto-compile-on-save-mode: t
  corfu-indexed-mode: t
  corfu-history-mode: t
  corfu-echo-mode: t
  corfu-doc-terminal-mode: t
  corfu-terminal-mode: t
  global-corfu-mode: t
  corfu-mode: t
  marginalia-mode: t
  vertico-mouse-mode: t
  vertico-indexed-mode: t
  vertico-mode: t
  xclip-mode: t
  save-place-mode: t
  global-goto-address-mode: t
  goto-address-mode: t
  savehist-mode: t
  minibuffer-depth-indicate-mode: t
  xterm-mouse-mode: t
  override-global-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/y1rog/.emacs.d/elpa/popon-0.13/popon hides /home/y1rog/.emacs.d/elpa/popon/popon
/home/y1rog/.emacs.d/elpa/popup-20210317.138/popup hides /usr/share/emacs/site-lisp/popup
/home/y1rog/.emacs.d/elpa/company-20221206.2122/company hides /usr/share/emacs/site-lisp/company-mode/company
/home/y1rog/.emacs.d/elpa/company-20221206.2122/company-files hides /usr/share/emacs/site-lisp/company-mode/company-files
/home/y1rog/.emacs.d/elpa/company-20221206.2122/company-etags hides /usr/share/emacs/site-lisp/company-mode/company-etags
/home/y1rog/.emacs.d/elpa/company-20221206.2122/company-capf hides /usr/share/emacs/site-lisp/company-mode/company-capf
/home/y1rog/.emacs.d/elpa/company-20221206.2122/company-keywords hides /usr/share/emacs/site-lisp/company-mode/company-keywords
/home/y1rog/.emacs.d/elpa/company-20221206.2122/company-dabbrev-code hides /usr/share/emacs/site-lisp/company-mode/company-dabbrev-code
/home/y1rog/.emacs.d/elpa/company-20221206.2122/company-bbdb hides /usr/share/emacs/site-lisp/company-mode/company-bbdb
/home/y1rog/.emacs.d/elpa/company-20221206.2122/company-dabbrev hides /usr/share/emacs/site-lisp/company-mode/company-dabbrev
/home/y1rog/.emacs.d/elpa/company-20221206.2122/company-template hides /usr/share/emacs/site-lisp/company-mode/company-template
/home/y1rog/.emacs.d/elpa/company-20221206.2122/company-gtags hides /usr/share/emacs/site-lisp/company-mode/company-gtags
/home/y1rog/.emacs.d/elpa/company-20221206.2122/company-semantic hides /usr/share/emacs/site-lisp/company-mode/company-semantic
/home/y1rog/.emacs.d/elpa/company-20221206.2122/company-yasnippet hides /usr/share/emacs/site-lisp/company-mode/company-yasnippet
/home/y1rog/.emacs.d/elpa/company-20221206.2122/company-elisp hides /usr/share/emacs/site-lisp/company-mode/company-elisp
/home/y1rog/.emacs.d/elpa/company-20221206.2122/company-css hides /usr/share/emacs/site-lisp/company-mode/company-css
/home/y1rog/.emacs.d/elpa/company-20221206.2122/company-cmake hides /usr/share/emacs/site-lisp/company-mode/company-cmake
/home/y1rog/.emacs.d/elpa/company-20221206.2122/company-clang hides /usr/share/emacs/site-lisp/company-mode/company-clang
/home/y1rog/.emacs.d/elpa/company-20221206.2122/company-tng hides /usr/share/emacs/site-lisp/company-mode/company-tng
/home/y1rog/.emacs.d/elpa/company-20221206.2122/company-tempo hides /usr/share/emacs/site-lisp/company-mode/company-tempo
/home/y1rog/.emacs.d/elpa/company-20221206.2122/company-oddmuse hides /usr/share/emacs/site-lisp/company-mode/company-oddmuse
/home/y1rog/.emacs.d/elpa/company-20221206.2122/company-nxml hides /usr/share/emacs/site-lisp/company-mode/company-nxml
/home/y1rog/.emacs.d/elpa/company-20221206.2122/company-abbrev hides /usr/share/emacs/site-lisp/company-mode/company-abbrev
/home/y1rog/.emacs.d/elpa/company-20221206.2122/company-ispell hides /usr/share/emacs/site-lisp/company-mode/company-ispell
/home/y1rog/.emacs.d/elpa/use-package-20210207.1926/use-package-bind-key hides /usr/share/emacs/site-lisp/use-package/use-package-bind-key
/home/y1rog/.emacs.d/elpa/use-package-20210207.1926/use-package-lint hides /usr/share/emacs/site-lisp/use-package/use-package-lint
/home/y1rog/.emacs.d/elpa/use-package-20210207.1926/use-package-diminish hides /usr/share/emacs/site-lisp/use-package/use-package-diminish
/home/y1rog/.emacs.d/elpa/use-package-20210207.1926/use-package-jump hides /usr/share/emacs/site-lisp/use-package/use-package-jump
/home/y1rog/.emacs.d/elpa/use-package-20210207.1926/use-package hides /usr/share/emacs/site-lisp/use-package/use-package
/home/y1rog/.emacs.d/elpa/use-package-20210207.1926/use-package-delight hides /usr/share/emacs/site-lisp/use-package/use-package-delight
/home/y1rog/.emacs.d/elpa/use-package-20210207.1926/use-package-core hides /usr/share/emacs/site-lisp/use-package/use-package-core
/home/y1rog/.emacs.d/elpa/use-package-20210207.1926/use-package-ensure hides /usr/share/emacs/site-lisp/use-package/use-package-ensure
/usr/share/emacs/site-lisp/use-package/bind-key hides /usr/share/emacs/30.0.50/lisp/bind-key
/home/y1rog/.emacs.d/elpa/transient-20221202.1727/transient hides /usr/share/emacs/30.0.50/lisp/transient
/home/y1rog/.emacs.d/elpa/use-package-20210207.1926/use-package-bind-key hides /usr/share/emacs/30.0.50/lisp/use-package/use-package-bind-key
/usr/share/emacs/site-lisp/use-package/use-package-ensure-system-package hides /usr/share/emacs/30.0.50/lisp/use-package/use-package-ensure-system-package
/home/y1rog/.emacs.d/elpa/use-package-20210207.1926/use-package-lint hides /usr/share/emacs/30.0.50/lisp/use-package/use-package-lint
/home/y1rog/.emacs.d/elpa/use-package-20210207.1926/use-package-diminish hides /usr/share/emacs/30.0.50/lisp/use-package/use-package-diminish
/home/y1rog/.emacs.d/elpa/use-package-20210207.1926/use-package-jump hides /usr/share/emacs/30.0.50/lisp/use-package/use-package-jump
/home/y1rog/.emacs.d/elpa/use-package-20210207.1926/use-package hides /usr/share/emacs/30.0.50/lisp/use-package/use-package
/home/y1rog/.emacs.d/elpa/use-package-20210207.1926/use-package-delight hides /usr/share/emacs/30.0.50/lisp/use-package/use-package-delight
/home/y1rog/.emacs.d/elpa/use-package-20210207.1926/use-package-core hides /usr/share/emacs/30.0.50/lisp/use-package/use-package-core
/home/y1rog/.emacs.d/elpa/use-package-20210207.1926/use-package-ensure hides /usr/share/emacs/30.0.50/lisp/use-package/use-package-ensure

Features:
(shadow emacsbug smerge-mode diff diff-mode shortdoc cus-edit cus-start
cus-load vertico-directory help-fns radix-tree org-element org-persist
org-id org-refile oc-basic ol-eww eww url-queue mm-url ol-rmail ol-mhe
ol-irc ol-info ol-gnus nnselect ol-docview doc-view filenotify jka-compr
image-mode exif ol-bibtex bibtex ol-bbdb ol-w3m ol-doi org-link-doi
shr-color qp mm-archive sort gnus-cite mail-extr textsec uni-scripts
idna-mapping ucs-normalize uni-confusable textsec-check my-email mu4e
mu4e-org org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro
org-src ob-comint org-pcomplete org-list org-footnote org-faces
org-entities ob-emacs-lisp ob-core ob-eval org-cycle org-table ol
org-fold org-fold-core org-keys oc org-loaddefs find-func org-version
org-compat org-macs mu4e-main mu4e-view gnus-art mm-uu mml2015 mm-view
mml-smime smime gnutls dig gnus-sum gnus-group gnus-undo gnus-start
gnus-dbus dbus gnus-cloud nnimap nnmail mail-source utf7 nnoo gnus-spec
gnus-int gnus-range gnus-win gnus nnheader range cal-menu calendar
cal-loaddefs mu4e-headers mu4e-compose mu4e-draft mu4e-actions smtpmail
mu4e-search mu4e-lists mu4e-bookmarks mu4e-mark mu4e-message shr
pixel-fill kinsoku url-file svg xml dom browse-url url url-proxy
url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util url-parse url-vars flow-fill
mule-util hl-line mu4e-contacts mu4e-update mu4e-folders mu4e-server
mu4e-context mu4e-obsolete mu4e-vars mu4e-helpers mu4e-config
mu4e-window bookmark pp ido message sendmail mailcap yank-media puny
dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068
epg-config gnus-util text-property-search mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr
mailabbrev mail-utils gmm-utils mailheader page-break-lines rainbow-mode
which-key openwith winner recentf tree-widget wid-edit browse-kill-ring
delsel windmove auto-compile comp comp-cstr cl-extra warnings packed
corfu-indexed corfu-info corfu-history cape-keyword cape corfu-echo
corfu-doc-terminal avl-tree generator corfu-doc corfu-terminal popon
corfu marginalia vertico-mouse vertico-buffer vertico-indexed vertico
xclip comp-run comp-common term/xterm xterm indent-bars treesit compat
noutline outline icons face-remap highlight-parentheses
sanityinc-tomorrow-eighties-theme color-theme-sanityinc-tomorrow color
my-key-bindings my-packages gnuplot-autoloads ediff ediff-merg
ediff-mult ediff-wind ediff-diff ediff-help ediff-init ediff-util
saveplace tramp-sh tramp rx trampver tramp-integration files-x
tramp-message help-mode tramp-compat xdg shell pcomplete comint ansi-osc
ring parse-time iso8601 time-date format-spec auth-source eieio
eieio-core password-cache json subr-x map ansi-color tramp-loaddefs
edmacro kmacro byte-opt diminish my-vertico-corfu my-tex
auctex-autoloads tex-site my-defaults goto-addr thingatpt savehist
mb-depth xt-mouse disp-table my-functions my-xterm cl-seq cl-macs gv
use-package use-package-ensure use-package-delight use-package-diminish
use-package-bind-key bind-key easy-mmode use-package-core cl-loaddefs
cl-lib bytecomp byte-compile info rmc iso-transl tooltip cconv eldoc
paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode
mwheel term/x-win x-win term/common-win x-dnd touch-screen tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo gtk
x-toolkit xinput2 x multi-tty move-toolbar make-network-process
native-compile emacs)

Memory information:
((conses 16 686735 101378) (symbols 48 31301 5)
 (strings 32 132848 5474) (string-bytes 1 3923210) (vectors 16 74276)
 (vector-slots 8 862021 26500) (floats 8 946 9980)
 (intervals 56 5825 1610) (buffers 984 19))

-- 
Olaf Rogalsky
Schwoerhausgasse 5
89073 Ulm
Germany

bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

[Eli Zaretskii]

> From: Olaf Rogalsky <olaf.rogalsky@t-online.de>
> Date: Wed, 20 Mar 2024 15:29:33 +0100
> 
> when using emacs in the terminal, the mouse-autoselect-window variable
> has no effect, i.e. moving the mouse from one window to the next does
> not change the selected window.
> 
> Recipe:
> --- snip ---
> emacs -nw
> M-: (xterm-mouse-mode 1)
> M-: (setq mouse-autoselect-window t)
> C-x 2
> <mouse-motion <<<other window>>> >
> --- snap ---
> 
> The reason is, that xt-mouse.el does not generate <select-window>
> events. The following patch fixes that.

Thanks.

> To this end, it also fixes a bug in "window.el". Here, the
> <select-window> event which is added to `last-input-event', does not
> contain a propper posn field. In X11, this works fine, but in the
> terminal it results in a "nil <select-window> is undefined" error.

On an MS-Windows terminal I don't see this problem, so maybe there's
more here than meets the eye?

Anyway, why do you call posn-at-point with first argument nil?  I
don't think the position of point in that window is at all relevant,
is it?  Should we perhaps use the position derived from mouse-position
instead?

Jared, any comments to this patch?

bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

[Olaf Rogalsky]

> On an MS-Windows terminal I don't see this problem, so maybe there's
> more here than meets the eye?
Yes, same in X11. I wasn't able to track it down. Maybe it is burried
deep inside of "read_char".

> Anyway, why do you call posn-at-point with first argument nil?  I
Because I was lazy and didn't thought, that "the position of point in that
window is at all relevant".


Eli Zaretskii <eliz@gnu.org> writes:

>> From: Olaf Rogalsky <olaf.rogalsky@t-online.de>
>> Date: Wed, 20 Mar 2024 15:29:33 +0100
>> 
>> when using emacs in the terminal, the mouse-autoselect-window variable
>> has no effect, i.e. moving the mouse from one window to the next does
>> not change the selected window.
>> 
>> Recipe:
>> --- snip ---
>> emacs -nw
>> M-: (xterm-mouse-mode 1)
>> M-: (setq mouse-autoselect-window t)
>> C-x 2
>> <mouse-motion <<<other window>>> >
>> --- snap ---
>> 
>> The reason is, that xt-mouse.el does not generate <select-window>
>> events. The following patch fixes that.
>
> Thanks.
>
>> To this end, it also fixes a bug in "window.el". Here, the
>> <select-window> event which is added to `last-input-event', does not
>> contain a propper posn field. In X11, this works fine, but in the
>> terminal it results in a "nil <select-window> is undefined" error.
>
> On an MS-Windows terminal I don't see this problem, so maybe there's
> more here than meets the eye?
>
> Anyway, why do you call posn-at-point with first argument nil?  I
> don't think the position of point in that window is at all relevant,
> is it?  Should we perhaps use the position derived from mouse-position
> instead?
>
> Jared, any comments to this patch?


-- 
Olaf Rogalsky
Schwoerhausgasse 5
89073 Ulm
Germany

bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

[Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 2024-03-20 11:10, Olaf Rogalsky wrote:
>> On an MS-Windows terminal I don't see this problem, so maybe there's
>> more here than meets the eye?
> Yes, same in X11. I wasn't able to track it down. Maybe it is burried
> deep inside of "read_char".

I tried this change locally on master without the change to window.el 
and everything worked fine for me. Are you certain you need the change 
to window.el as well? I'd be very surprised if it is necessary to change 
the structure of the <select-window> event to get autoselect to work.

My repro was just:

src/emacs -nw -Q
M-x xterm-mouse-mode
M-x set-variable RET mouse-autoselect-window RET t
C-x 2
C-x 3
Then moving the mouse between the three visible windows.

Is your setup is different somehow?


A few other pieces of feedback (you may find it easier to generate the 
events in xterm-mouse-translate-1 to address):

<select-window> 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.

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.

Did you try out switching frames? I'm not certain if <select-window> is 
supposed to be generated when the frame is switched.

Please name the new internal state variable with prefix "xt-mouse--".

   -- MJF

bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

[Olaf Rogalsky]

Hi Jared,

thanks for your feedback (answering this from my gmail account and
hope this doesn't mess up the debbugs history).

> A few other pieces of feedback (you may find it easier to generate the
> events in xterm-mouse-translate-1 to address):
Yes, I think you are right. I refactored my code accordingly, see the new patch
below.

> 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 <select-window> 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.

> <select-window> 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
 <help-echo> 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
 <drag-mouse-1>                        ;; 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.

> 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?

> Did you try out switching frames? I'm not certain if <select-window> 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.

> Please name the new internal state variable with prefix "xt-mouse--".
I changed it to the terminal parameter xterm-mouse-last-window.

Regards, Olaf

New patch:
diff --git a/lisp/xt-mouse.el b/lisp/xt-mouse.el
index 081b8f32456..8b405262168 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,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
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
+           (progn
+             (put 'select-window 'event-kind 'switch-frame)
+             (setf (car event) 'select-window)
+             vec)
+          (if track-mouse vec
+            ;; Mouse movement events are currently supposed to be
+            ;; suppressed.  Return no event.
+            [])))
        (t
        (let* ((down (terminal-parameter nil 'xterm-mouse-last-down))
               (down-data (nth 1 down))

bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

[Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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 <select-window> 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.

>> <select-window> 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
>  <help-echo> 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
>  <drag-mouse-1>                        ;; 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 <select-window> 
>> 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

bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

[Eli Zaretskii]

> Date: Mon, 25 Mar 2024 14:53:15 -0700
> From: Jared Finder <jared@finder.org>
> Cc: eliz@gnu.org, 69915@debbugs.gnu.org
> 
> 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 <select-window> 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.

I agree.

Olaf, if leaving window.el unchanged causes these errors, please show
a recipe for reproducing it, and let's try to investigate why it
happens, before we decide how to fix it.

bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

[Olaf Rogalsky]

Hi Jared,

 > 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 <select-window> 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.

I can't reproduce the error anymore, so I would leave it as is.


 > >> <select-window> 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
 > >  <help-echo> 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
 > >  <drag-mouse-1>                        ;; 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?

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:


mouse-movement to #<window 1 on *scratch*> at posn (65 . 40)
mouse-movement to #<window 1 on *scratch*> at posn (65 . 41)
select-window to #<window 4 on *scratch*> at posn (65 . 0)
mouse-movement to #<window 4 on *scratch*> at posn (64 . 0)
mouse-movement to #<window 4 on *scratch*> at posn (64 . 1)
=> select-window event is reported, but at a different posn as the next or
previous mouse-movement. So no simultaneous events for mouse-movement
and select-window.

Result for X11 backend

mouse-movement to #<window 3 on *scratch*> at posn (433 . 983)
mouse-movement to #<window 3 on *scratch*> at posn (432 . 1009)
mouse-movement to #<window 15 on *scratch*> at posn (423 . 0)
mouse-movement to #<window 15 on *scratch*> at posn (420 . 24)
=> no select-window event is reported to read-key at all!

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:


mouse-movement to #<window 1 on *scratch*> at posn (65 . 40)
mouse-movement to #<window 1 on *scratch*> at posn (65 . 41)
select-window to #<window 4 on *scratch*> at posn (65 . 0)
mouse-movement to #<window 4 on *scratch*> at posn (64 . 0)
mouse-movement to #<window 4 on *scratch*> at posn (64 . 1)
=> same as result for test case 1

Result for X11 backend:

mouse-movement to #<window 1 on *scratch*> at posn (43 . 39)
mouse-movement to #<window 1 on *scratch*> at posn (43 . 40)
select-window to #<window 4 on *scratch*> at posn (43 . 0)
mouse-movement to #<window 4 on *scratch*> at posn (43 . 1)
mouse-movement to #<window 4 on *scratch*> at posn (43 . 2)
=> Now a select window event is reported as in the terminal. And also
for X11: no simultaneous events for mouse-movement and select-window.

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.


 > >> Did you try out switching frames? I'm not certain if <select-window> 
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.

Good!


 > > 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))?

yes, of cause

 > > 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 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?


 > > +           (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.

Please find below the next iteration of the patch.
Olaf







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))

bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

[Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 2024-03-26 16:50, Olaf Rogalsky wrote:
> Hi Jared,
> 
>> >> <select-window> 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 
<select-window> event, try pushing the <select-window> 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))

bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

[Eli Zaretskii]

> Date: Wed, 27 Mar 2024 14:47:27 -0700
> From: Jared Finder <jared@finder.org>
> Cc: eliz@gnu.org, 69915@debbugs.gnu.org
> 
> > 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 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.

> > 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?

> >> > +           (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.

I agree.

> > 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.

Thanks, please post the final version after these minor changes for
review.

Thanks.

bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

[Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 2024-03-27 23:11, Eli Zaretskii wrote:
>> Date: Wed, 27 Mar 2024 14:47:27 -0700
>> From: Jared Finder <jared@finder.org>
>> Cc: eliz@gnu.org, 69915@debbugs.gnu.org
>> 
>> > 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 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.

The intended behavior is that is even with mouse-autoselect-window set, 
moving the mouse is never supposed to change the selected window away 
from the minibuffer.  Many platforms explicitly check if the selected 
window is the minibuffer before emitting the <select-window> event, but 
not all platforms do (see list above).

And on all platforms, including ones without the explicit check we get 
the intended behavior from our testing.

So my question is should we copy the explicit check to prevent 
<select-window> events from being emitted to xt-mouse.el as well, even 
though it does not appear to be necessary from our testing?

   -- MJF

bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

[Olaf Rogalsky]

[-- Attachment #1: Type: text/plain, Size: 4680 bytes --]

Hi Jared and Eli,

Jared Finder <jared@finder.org> writes:
> On 2024-03-26 16:50, Olaf Rogalsky wrote:
>> Hi Jared,
>> 
>>> >> <select-window> 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
> <select-window> event, try pushing the <select-window> 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.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-user-option-mouse-autoselect-window-for-tty-emac.patch --]
[-- Type: text/x-patch, Size: 2732 bytes --]

From 8de818075ff5e583e25d4f408b9333fac2c37a3c Mon Sep 17 00:00:00 2001
From: Olaf Rogalsky <olaf.rogalsky@gmail.com>
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))

bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

[Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 895 bytes --]

I am happy with the contents of Olaf's patch.  I would just do some 
minor reformatting at this point: converting tabs to spaces, removing 
commented out line, change comment wording slightly.

On 2024-03-30 10:03, Olaf Rogalsky wrote:
> Hi Jared and Eli,
> 
>>> 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.

I took a stab at generating documentation here.  I'm not that familiar 
with texi format either, so I'd appreciate a review.

> PS: sorry for the horrible formatting of the previous messages: I
> usually do not use my gmail account ... Hope, this one comes out 
> better.

No worries, everything looked fine to me!

   -- MJF

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Adding-documentation-for-switch-window-event.patch --]
[-- Type: text/x-diff; name=0001-Adding-documentation-for-switch-window-event.patch, Size: 5358 bytes --]

From 7cd83458caa3940f8a826233c1903bc69aafdef8 Mon Sep 17 00:00:00 2001
From: Jared Finder <jared@finder.org>
Date: Sat, 30 Mar 2024 13:14:43 -0700
Subject: [PATCH] Adding documentation for <switch-window> event

* doc/lispref/commands.texi (Focus Events): Adding documentation
for the structure of <switch-window> events.  Making sure to be
clear when referring to window system windows vs Emacs windows.
* doc/lispref/windows.texi (Mouse Window Auto-selection): Adding
link to Focus Events.
---
 doc/lispref/commands.texi | 66 ++++++++++++++++++++++++++++-----------
 doc/lispref/windows.texi  |  2 +-
 2 files changed, 48 insertions(+), 20 deletions(-)

diff --git a/doc/lispref/commands.texi b/doc/lispref/commands.texi
index 4fe4969c0db..335a41dbb44 100644
--- a/doc/lispref/commands.texi
+++ b/doc/lispref/commands.texi
@@ -2303,15 +2303,34 @@ Focus Events
 @subsection Focus Events
 @cindex focus event
 
+This section talks about both window systems and Emacs frames.  When
+talking about just ``frames'' or ``windows'', it refers to Emacs frames
+and Emacs windows.  When talking about window system windows, which are
+also Emacs frames, this section always says ``window system window''.
+
+@noindent
 Window systems provide general ways for the user to control which window
-gets keyboard input.  This choice of window is called the @dfn{focus}.
-When the user does something to switch between Emacs frames, that
-generates a @dfn{focus event}.  The normal definition of a focus event,
-in the global keymap, is to select a new frame within Emacs, as the user
-would expect.  @xref{Input Focus}, which also describes hooks related
-to focus events.
+system window, or Emacs frame, gets keyboard input.  This choice of
+window system window is called the @dfn{focus}.  When the user does
+something to switch between Emacs frames, that generates a @dfn{focus
+event}.  Emacs also generates focus events when using
+@var{mouse-autoselect-window} to switch between Emacs windows within
+Emacs frames.
+
+A focus event in the middle of a key sequence would garble the
+sequence.  So Emacs never generates a focus event in the middle of a key
+sequence.  If the user changes focus in the middle of a key
+sequence---that is, after a prefix key---then Emacs reorders the events
+so that the focus event comes either before or after the multi-event key
+sequence, and not within it.
 
-Focus events are represented in Lisp as lists that look like this:
+@heading Focus events for frames
+
+The normal definition of a focus event that switches frames, in the
+global keymap, is to select that new frame within Emacs, as the user
+would expect.  @xref{Input Focus}, which also describes hooks related to
+focus events for frames.  Focus events for frames are represented in
+Lisp as lists that look like this:
 
 @example
 (switch-frame @var{new-frame})
@@ -2321,19 +2340,28 @@ Focus Events
 where @var{new-frame} is the frame switched to.
 
 Some X window managers are set up so that just moving the mouse into a
-window is enough to set the focus there.  Usually, there is no need
-for a Lisp program to know about the focus change until some other
-kind of input arrives.  Emacs generates a focus event only when the
-user actually types a keyboard key or presses a mouse button in the
-new frame; just moving the mouse between frames does not generate a
-focus event.
+frame is enough to set the focus there.  Usually, there is no need for a
+Lisp program to know about the focus change until some other kind of
+input arrives.  Emacs generates a focus event only when the user
+actually types a keyboard key or presses a mouse button in the new
+frame; just moving the mouse between frames does not generate a focus
+event.
 
-A focus event in the middle of a key sequence would garble the
-sequence.  So Emacs never generates a focus event in the middle of a key
-sequence.  If the user changes focus in the middle of a key
-sequence---that is, after a prefix key---then Emacs reorders the events
-so that the focus event comes either before or after the multi-event key
-sequence, and not within it.
+@heading Focus events for windows
+
+When @var{mouse-autoselect-window} is set, moving the mouse over a new
+window within a frame can also switch the selected window.  @xref{Mouse
+Window Auto-selection}, which describes the behavior for different
+values.  When the mouse is moved over a new window, a focus event for
+switching windows is generated.  Focus events for windows are
+reperesented in Lisp as lists that look like this:
+
+@example
+(select-window @var{new-window})
+@end example
+
+@noindent
+where @var{new-window} is the window switched to.
 
 @node Xwidget Events
 @subsection Xwidget events
diff --git a/doc/lispref/windows.texi b/doc/lispref/windows.texi
index eef05d94fdb..54ef3851820 100644
--- a/doc/lispref/windows.texi
+++ b/doc/lispref/windows.texi
@@ -6177,7 +6177,7 @@ Mouse Window Auto-selection
 the mouse pointer.  This accomplishes a policy similar to that of
 window managers that give focus to a frame (and thus trigger its
 subsequent selection) whenever the mouse pointer enters its
-window-system window (@pxref{Input Focus}).
+window-system window (@pxref{Input Focus}, @pxref{Focus Events}).
 
 @defopt mouse-autoselect-window
 If this variable is non-@code{nil}, Emacs will try to automatically
-- 
2.39.2

bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

[Eli Zaretskii]

> Date: Thu, 28 Mar 2024 07:41:28 -0700
> From: Jared Finder <jared@finder.org>
> Cc: olaf.rogalsky@gmail.com, 69915@debbugs.gnu.org
> 
> On 2024-03-27 23:11, Eli Zaretskii wrote:
> >> Date: Wed, 27 Mar 2024 14:47:27 -0700
> >> From: Jared Finder <jared@finder.org>
> >> Cc: eliz@gnu.org, 69915@debbugs.gnu.org
> >> 
> >> > 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 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.
> 
> The intended behavior is that is even with mouse-autoselect-window set, 
> moving the mouse is never supposed to change the selected window away 
> from the minibuffer.  Many platforms explicitly check if the selected 
> window is the minibuffer before emitting the <select-window> event, but 
> not all platforms do (see list above).
> 
> And on all platforms, including ones without the explicit check we get 
> the intended behavior from our testing.
> 
> So my question is should we copy the explicit check to prevent 
> <select-window> events from being emitted to xt-mouse.el as well, even 
> though it does not appear to be necessary from our testing?

The mini-window test was added by Martin, AFAICT, as part of rewriting
the mouse-autoselect-window support.  Martin, do you remember why you
added the MINI_WINDOW_P test in xterm.c, but not, for example, in
w32term.c?

In any case, I couldn't find any problems with the current behavior on
MS-Windows when mouse-autoselect-window is non-nil.

bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 >> The intended behavior is that is even with mouse-autoselect-window set,
 >> moving the mouse is never supposed to change the selected window away
 >> from the minibuffer.  Many platforms explicitly check if the selected
 >> window is the minibuffer before emitting the <select-window> event, but
 >> not all platforms do (see list above).
 >>
 >> And on all platforms, including ones without the explicit check we get
 >> the intended behavior from our testing.
 >>
 >> So my question is should we copy the explicit check to prevent
 >> <select-window> events from being emitted to xt-mouse.el as well, even
 >> though it does not appear to be necessary from our testing?
 >
 > The mini-window test was added by Martin, AFAICT, as part of rewriting
 > the mouse-autoselect-window support.  Martin, do you remember why you
 > added the MINI_WINDOW_P test in xterm.c, but not, for example, in
 > w32term.c?
 >
 > In any case, I couldn't find any problems with the current behavior on
 > MS-Windows when mouse-autoselect-window is non-nil.

The original mini-window test was conceived by Stefan

commit 66c226bf5a1e8289b0ce676d5e4225810a11af91
Author: Stefan Monnier <monnier@iro.umontreal.ca>
Date:   Thu Jan 20 14:23:23 2005 +0000

     (handle-select-window): Don't switch window when we're in the minibuffer.

and I moved it to xterm.c later.  I don't remember why and all I
remember is that the accompanying comment was not mine.

The check is redundant because the condition is tested again here in
'handle-select-window':

                 ;; Don't switch if window autoselection with mouse is active
                 ;; and minibuffer window is selected.
                 (and mouse-autoselect-window (window-minibuffer-p))

One could say that the xterm.c code is more efficient because it doesn't
generate a SELECT_WINDOW_EVENT when the selected window is the
minibuffer window.  The w32 code generates the event but has it
dismissed later in 'handle-select-window'.

In either case I would not remove the check from 'handle-select-window'
because that one is platform-independent so there's no need to implement
anything separately in the backends.

Though it might be more accurate to replace 'window-minibuffer-p' with
'minibuffer-window-active-p' to catch the case where a user, for some
reason, selects the minibuffer window manually without activating the
minibuffer.  And the 'mouse-autoselect-window' conjunct above is likely
redundant...

martin

bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

[Eli Zaretskii]

> Date: Mon, 1 Apr 2024 11:09:47 +0200
> Cc: olaf.rogalsky@gmail.com, 69915@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  > The mini-window test was added by Martin, AFAICT, as part of rewriting
>  > the mouse-autoselect-window support.  Martin, do you remember why you
>  > added the MINI_WINDOW_P test in xterm.c, but not, for example, in
>  > w32term.c?
>  >
>  > In any case, I couldn't find any problems with the current behavior on
>  > MS-Windows when mouse-autoselect-window is non-nil.
> 
> The original mini-window test was conceived by Stefan
> 
> commit 66c226bf5a1e8289b0ce676d5e4225810a11af91
> Author: Stefan Monnier <monnier@iro.umontreal.ca>
> Date:   Thu Jan 20 14:23:23 2005 +0000
> 
>      (handle-select-window): Don't switch window when we're in the minibuffer.
> 
> and I moved it to xterm.c later.  I don't remember why and all I
> remember is that the accompanying comment was not mine.
> 
> The check is redundant because the condition is tested again here in
> 'handle-select-window':
> 
>                  ;; Don't switch if window autoselection with mouse is active
>                  ;; and minibuffer window is selected.
>                  (and mouse-autoselect-window (window-minibuffer-p))
> 
> One could say that the xterm.c code is more efficient because it doesn't
> generate a SELECT_WINDOW_EVENT when the selected window is the
> minibuffer window.  The w32 code generates the event but has it
> dismissed later in 'handle-select-window'.
> 
> In either case I would not remove the check from 'handle-select-window'
> because that one is platform-independent so there's no need to implement
> anything separately in the backends.
> 
> Though it might be more accurate to replace 'window-minibuffer-p' with
> 'minibuffer-window-active-p' to catch the case where a user, for some
> reason, selects the minibuffer window manually without activating the
> minibuffer.  And the 'mouse-autoselect-window' conjunct above is likely
> redundant...

Thanks.

Jared and Olaf, so I think the minibuffer test in the patch should
stay, but please see Martin's suggestions above.

bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

[Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 2024-04-01 04:40, Eli Zaretskii wrote:
>> Date: Mon, 1 Apr 2024 11:09:47 +0200
>> Cc: olaf.rogalsky@gmail.com, 69915@debbugs.gnu.org
>> From: martin rudalics <rudalics@gmx.at>
>> 
>>  > The mini-window test was added by Martin, AFAICT, as part of 
>> rewriting
>>  > the mouse-autoselect-window support.  Martin, do you remember why 
>> you
>>  > added the MINI_WINDOW_P test in xterm.c, but not, for example, in
>>  > w32term.c?
>>  >
>>  > In any case, I couldn't find any problems with the current behavior 
>> on
>>  > MS-Windows when mouse-autoselect-window is non-nil.
>> 
>> The original mini-window test was conceived by Stefan
>> 
>> commit 66c226bf5a1e8289b0ce676d5e4225810a11af91
>> Author: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date:   Thu Jan 20 14:23:23 2005 +0000
>> 
>>      (handle-select-window): Don't switch window when we're in the 
>> minibuffer.
>> 
>> and I moved it to xterm.c later.  I don't remember why and all I
>> remember is that the accompanying comment was not mine.
>> 
>> The check is redundant because the condition is tested again here in
>> 'handle-select-window':
>> 
>>                  ;; Don't switch if window autoselection with mouse is 
>> active
>>                  ;; and minibuffer window is selected.
>>                  (and mouse-autoselect-window (window-minibuffer-p))
>> 
>> One could say that the xterm.c code is more efficient because it 
>> doesn't
>> generate a SELECT_WINDOW_EVENT when the selected window is the
>> minibuffer window.  The w32 code generates the event but has it
>> dismissed later in 'handle-select-window'.
>> 
>> In either case I would not remove the check from 
>> 'handle-select-window'
>> because that one is platform-independent so there's no need to 
>> implement
>> anything separately in the backends.
>> 
>> Though it might be more accurate to replace 'window-minibuffer-p' with
>> 'minibuffer-window-active-p' to catch the case where a user, for some
>> reason, selects the minibuffer window manually without activating the
>> minibuffer.  And the 'mouse-autoselect-window' conjunct above is 
>> likely
>> redundant...
> 
> Thanks.
> 
> Jared and Olaf, so I think the minibuffer test in the patch should
> stay, but please see Martin's suggestions above.

Martin, did you mean we should change Olaf's patch to xt-mouse.el use 
minibuffer-window-active-p or we should change handle-select-window in 
window.el to use minibuffer-window-active-p?

I have a preference to keep xt-mouse.el aligned with xterm.c as well as 
other native code checks, all which use MINI_WINDOW_P 
(window-minibuffer-p in Lisp) currently.

   -- MJF

bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > Martin, did you mean we should change Olaf's patch to xt-mouse.el use
 > minibuffer-window-active-p or we should change handle-select-window in
 > window.el to use minibuffer-window-active-p?
 >
 > I have a preference to keep xt-mouse.el aligned with xterm.c as well
 > as other native code checks, all which use MINI_WINDOW_P
 > (window-minibuffer-p in Lisp) currently.

'minibuffer-window-active-p' should be more accurate but I do not fully
understand its semantics any more.  For anything you and Olaf do, I'd
recommend 'window-minibuffer-p' / MINI_WINDOW_P.

martin

bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

[Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 2024-04-01 04:40, Eli Zaretskii wrote:
> On 2024-04-02 00:50, martin rudalics wrote:
>> Jared and Olaf, so I think the minibuffer test in the patch should
>> stay, but please see Martin's suggestions above.
> 
>> Martin, did you mean we should change Olaf's patch to xt-mouse.el use
>> minibuffer-window-active-p or we should change handle-select-window in
>> window.el to use minibuffer-window-active-p?
>> 
>> I have a preference to keep xt-mouse.el aligned with xterm.c as well
>> as other native code checks, all which use MINI_WINDOW_P
>> (window-minibuffer-p in Lisp) currently.
> 
> 'minibuffer-window-active-p' should be more accurate but I do not fully
> understand its semantics any more.  For anything you and Olaf do, I'd
> recommend 'window-minibuffer-p' / MINI_WINDOW_P.

Eli, given this feedback I don't think Olaf's patch should be altered as 
it currently uses window-minibuffer-p.  Let me know if you would like 
any further changes.

   -- MJF

bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

[Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Apologies, the manual quoting I did here for context was incorrectly 
done in the previous email.  I have corrected that.

>>>> Jared and Olaf, so I think the minibuffer test in the patch should
>>>> stay, but please see Martin's suggestions above.
>>> 
>>> Martin, did you mean we should change Olaf's patch to xt-mouse.el use
>>> minibuffer-window-active-p or we should change handle-select-window 
>>> in
>>> window.el to use minibuffer-window-active-p?
>>> 
>>> I have a preference to keep xt-mouse.el aligned with xterm.c as well
>>> as other native code checks, all which use MINI_WINDOW_P
>>> (window-minibuffer-p in Lisp) currently.
>> 
>> 'minibuffer-window-active-p' should be more accurate but I do not 
>> fully
>> understand its semantics any more.  For anything you and Olaf do, I'd
>> recommend 'window-minibuffer-p' / MINI_WINDOW_P.
> 
> Eli, given this feedback I don't think Olaf's patch should be altered 
> as it currently uses window-minibuffer-p.  Let me know if you would 
> like any further changes.
> 
>   -- MJF

bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

[Eli Zaretskii]

> Date: Thu, 04 Apr 2024 09:32:28 -0700
> From: Jared Finder <jared@finder.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, olaf.rogalsky@gmail.com,
>  69915@debbugs.gnu.org
> 
> Eli, given this feedback I don't think Olaf's patch should be altered as 
> it currently uses window-minibuffer-p.  Let me know if you would like 
> any further changes.

Thanks, I installed both Olaf's and your changes, and I'm therefore
closing this bug.

P.S. Please note that @heading is not TRT inside a @subsection; I
fixed that.

bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal

[Olaf Rogalsky]

help-debbugs@gnu.org (GNU bug Tracking System) writes:
> Your bug report
>
> #69915: 30.0.50; mouse-autoselect-window has no effect in terminal
>
> which was filed against the emacs package, has been closed.


Thanks everyone for assistance and for applying the patch!

Regards, Olaf