Package: emacs;
Reported by: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>
Date: Wed, 20 Mar 2024 14:56:01 UTC
Severity: normal
Found in version 30.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 69915 in the body.
You can then email your comments to 69915 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org
:bug#69915
; Package emacs
.
(Wed, 20 Mar 2024 14:56:01 GMT) Full text and rfc822 format available.Olaf Rogalsky <olaf.rogalsky <at> t-online.de>
:bug-gnu-emacs <at> gnu.org
.
(Wed, 20 Mar 2024 14:56:01 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Olaf Rogalsky <olaf.rogalsky <at> t-online.de> To: bug-gnu-emacs <at> gnu.org Subject: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Wed, 20 Mar 2024 15:29:33 +0100
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-gnu-emacs <at> gnu.org
:bug#69915
; Package emacs
.
(Wed, 20 Mar 2024 16:45:02 GMT) Full text and rfc822 format available.Message #8 received at 69915 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>, Jared Finder <jared <at> finder.org> Cc: 69915 <at> debbugs.gnu.org Subject: Re: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Wed, 20 Mar 2024 18:43:11 +0200
> From: Olaf Rogalsky <olaf.rogalsky <at> 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-gnu-emacs <at> gnu.org
:bug#69915
; Package emacs
.
(Wed, 20 Mar 2024 18:56:01 GMT) Full text and rfc822 format available.Message #11 received at 69915 <at> debbugs.gnu.org (full text, mbox):
From: Olaf Rogalsky <olaf.rogalsky <at> t-online.de> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 69915 <at> debbugs.gnu.org, Jared Finder <jared <at> finder.org> Subject: Re: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Wed, 20 Mar 2024 19:10:53 +0100
> 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 <at> gnu.org> writes: >> From: Olaf Rogalsky <olaf.rogalsky <at> 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-gnu-emacs <at> gnu.org
:bug#69915
; Package emacs
.
(Thu, 21 Mar 2024 17:02:02 GMT) Full text and rfc822 format available.Message #14 received at 69915 <at> debbugs.gnu.org (full text, mbox):
From: Jared Finder <jared <at> finder.org> To: Olaf Rogalsky <olaf.rogalsky <at> t-online.de> Cc: 69915 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org> Subject: Re: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Thu, 21 Mar 2024 10:00:51 -0700
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-gnu-emacs <at> gnu.org
:bug#69915
; Package emacs
.
(Sun, 24 Mar 2024 19:30:02 GMT) Full text and rfc822 format available.Message #17 received at 69915 <at> debbugs.gnu.org (full text, mbox):
From: Olaf Rogalsky <olaf.rogalsky <at> gmail.com> To: Jared Finder <jared <at> finder.org> Cc: 69915 <at> debbugs.gnu.org, "eliz <at> gnu.org" <eliz <at> gnu.org> Subject: Re: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Sun, 24 Mar 2024 20:27:55 +0100
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-gnu-emacs <at> gnu.org
:bug#69915
; Package emacs
.
(Mon, 25 Mar 2024 21:54:02 GMT) Full text and rfc822 format available.Message #20 received at 69915 <at> debbugs.gnu.org (full text, mbox):
From: Jared Finder <jared <at> finder.org> To: Olaf Rogalsky <olaf.rogalsky <at> gmail.com> Cc: 69915 <at> debbugs.gnu.org, eliz <at> gnu.org Subject: Re: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Mon, 25 Mar 2024 14:53:15 -0700
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-gnu-emacs <at> gnu.org
:bug#69915
; Package emacs
.
(Tue, 26 Mar 2024 13:45:02 GMT) Full text and rfc822 format available.Message #23 received at 69915 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Jared Finder <jared <at> finder.org> Cc: olaf.rogalsky <at> gmail.com, 69915 <at> debbugs.gnu.org Subject: Re: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Tue, 26 Mar 2024 14:31:03 +0200
> Date: Mon, 25 Mar 2024 14:53:15 -0700 > From: Jared Finder <jared <at> finder.org> > Cc: eliz <at> gnu.org, 69915 <at> 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-gnu-emacs <at> gnu.org
:bug#69915
; Package emacs
.
(Tue, 26 Mar 2024 23:51:02 GMT) Full text and rfc822 format available.Message #26 received at 69915 <at> debbugs.gnu.org (full text, mbox):
From: Olaf Rogalsky <olaf.rogalsky <at> gmail.com> To: Jared Finder <jared <at> finder.org> Cc: 69915 <at> debbugs.gnu.org, eliz <at> gnu.org Subject: Re: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Tue, 26 Mar 2024 23:50:45 +0000
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-gnu-emacs <at> gnu.org
:bug#69915
; Package emacs
.
(Wed, 27 Mar 2024 21:48:02 GMT) Full text and rfc822 format available.Message #29 received at 69915 <at> debbugs.gnu.org (full text, mbox):
From: Jared Finder <jared <at> finder.org> To: Olaf Rogalsky <olaf.rogalsky <at> gmail.com> Cc: 69915 <at> debbugs.gnu.org, eliz <at> gnu.org Subject: Re: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Wed, 27 Mar 2024 14:47:27 -0700
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-gnu-emacs <at> gnu.org
:bug#69915
; Package emacs
.
(Thu, 28 Mar 2024 06:12:02 GMT) Full text and rfc822 format available.Message #32 received at 69915 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Jared Finder <jared <at> finder.org> Cc: olaf.rogalsky <at> gmail.com, 69915 <at> debbugs.gnu.org Subject: Re: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Thu, 28 Mar 2024 08:11:15 +0200
> Date: Wed, 27 Mar 2024 14:47:27 -0700 > From: Jared Finder <jared <at> finder.org> > Cc: eliz <at> gnu.org, 69915 <at> 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-gnu-emacs <at> gnu.org
:bug#69915
; Package emacs
.
(Thu, 28 Mar 2024 14:42:02 GMT) Full text and rfc822 format available.Message #35 received at 69915 <at> debbugs.gnu.org (full text, mbox):
From: Jared Finder <jared <at> finder.org> To: Eli Zaretskii <eliz <at> gnu.org> Cc: olaf.rogalsky <at> gmail.com, 69915 <at> debbugs.gnu.org Subject: Re: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Thu, 28 Mar 2024 07:41:28 -0700
On 2024-03-27 23:11, Eli Zaretskii wrote: >> Date: Wed, 27 Mar 2024 14:47:27 -0700 >> From: Jared Finder <jared <at> finder.org> >> Cc: eliz <at> gnu.org, 69915 <at> 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-gnu-emacs <at> gnu.org
:bug#69915
; Package emacs
.
(Sat, 30 Mar 2024 17:08:01 GMT) Full text and rfc822 format available.Message #38 received at 69915 <at> debbugs.gnu.org (full text, mbox):
From: Olaf Rogalsky <olaf.rogalsky <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 69915 <at> debbugs.gnu.org, Jared Finder <jared <at> finder.org> Subject: Re: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Sat, 30 Mar 2024 18:03:37 +0100
[Message part 1 (text/plain, inline)]
Hi Jared and Eli, Jared Finder <jared <at> 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.
[0001-Fix-user-option-mouse-autoselect-window-for-tty-emac.patch (text/x-patch, inline)]
From 8de818075ff5e583e25d4f408b9333fac2c37a3c Mon Sep 17 00:00:00 2001 From: Olaf Rogalsky <olaf.rogalsky <at> 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-gnu-emacs <at> gnu.org
:bug#69915
; Package emacs
.
(Sat, 30 Mar 2024 20:19:01 GMT) Full text and rfc822 format available.Message #41 received at 69915 <at> debbugs.gnu.org (full text, mbox):
From: Jared Finder <jared <at> finder.org> To: Olaf Rogalsky <olaf.rogalsky <at> gmail.com> Cc: 69915 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org> Subject: Re: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Sat, 30 Mar 2024 13:18:01 -0700
[Message part 1 (text/plain, inline)]
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
[0001-Adding-documentation-for-switch-window-event.patch (text/x-diff, attachment)]
bug-gnu-emacs <at> gnu.org
:bug#69915
; Package emacs
.
(Sun, 31 Mar 2024 08:59:02 GMT) Full text and rfc822 format available.Message #44 received at 69915 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Jared Finder <jared <at> finder.org>, martin rudalics <rudalics <at> gmx.at> Cc: olaf.rogalsky <at> gmail.com, 69915 <at> debbugs.gnu.org Subject: Re: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Sun, 31 Mar 2024 11:58:36 +0300
> Date: Thu, 28 Mar 2024 07:41:28 -0700 > From: Jared Finder <jared <at> finder.org> > Cc: olaf.rogalsky <at> gmail.com, 69915 <at> 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 <at> finder.org> > >> Cc: eliz <at> gnu.org, 69915 <at> 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-gnu-emacs <at> gnu.org
:bug#69915
; Package emacs
.
(Mon, 01 Apr 2024 09:11:02 GMT) Full text and rfc822 format available.Message #47 received at 69915 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org>, Jared Finder <jared <at> finder.org> Cc: olaf.rogalsky <at> gmail.com, 69915 <at> debbugs.gnu.org Subject: Re: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Mon, 1 Apr 2024 11:09:47 +0200
>> 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 <at> 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-gnu-emacs <at> gnu.org
:bug#69915
; Package emacs
.
(Mon, 01 Apr 2024 11:42:02 GMT) Full text and rfc822 format available.Message #50 received at 69915 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: olaf.rogalsky <at> gmail.com, 69915 <at> debbugs.gnu.org, jared <at> finder.org Subject: Re: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Mon, 01 Apr 2024 14:40:29 +0300
> Date: Mon, 1 Apr 2024 11:09:47 +0200 > Cc: olaf.rogalsky <at> gmail.com, 69915 <at> debbugs.gnu.org > From: martin rudalics <rudalics <at> 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 <at> 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-gnu-emacs <at> gnu.org
:bug#69915
; Package emacs
.
(Mon, 01 Apr 2024 14:09:01 GMT) Full text and rfc822 format available.Message #53 received at 69915 <at> debbugs.gnu.org (full text, mbox):
From: Jared Finder <jared <at> finder.org> To: Eli Zaretskii <eliz <at> gnu.org> Cc: olaf.rogalsky <at> gmail.com, martin rudalics <rudalics <at> gmx.at>, 69915 <at> debbugs.gnu.org Subject: Re: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Mon, 01 Apr 2024 07:08:25 -0700
On 2024-04-01 04:40, Eli Zaretskii wrote: >> Date: Mon, 1 Apr 2024 11:09:47 +0200 >> Cc: olaf.rogalsky <at> gmail.com, 69915 <at> debbugs.gnu.org >> From: martin rudalics <rudalics <at> 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 <at> 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-gnu-emacs <at> gnu.org
:bug#69915
; Package emacs
.
(Tue, 02 Apr 2024 07:51:02 GMT) Full text and rfc822 format available.Message #56 received at 69915 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Jared Finder <jared <at> finder.org>, Eli Zaretskii <eliz <at> gnu.org> Cc: olaf.rogalsky <at> gmail.com, 69915 <at> debbugs.gnu.org Subject: Re: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Tue, 2 Apr 2024 09:50:40 +0200
> 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-gnu-emacs <at> gnu.org
:bug#69915
; Package emacs
.
(Thu, 04 Apr 2024 16:33:02 GMT) Full text and rfc822 format available.Message #59 received at 69915 <at> debbugs.gnu.org (full text, mbox):
From: Jared Finder <jared <at> finder.org> To: martin rudalics <rudalics <at> gmx.at> Cc: olaf.rogalsky <at> gmail.com, 69915 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org> Subject: Re: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Thu, 04 Apr 2024 09:32:28 -0700
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-gnu-emacs <at> gnu.org
:bug#69915
; Package emacs
.
(Thu, 04 Apr 2024 16:42:02 GMT) Full text and rfc822 format available.Message #62 received at 69915 <at> debbugs.gnu.org (full text, mbox):
From: Jared Finder <jared <at> finder.org> To: martin rudalics <rudalics <at> gmx.at> Cc: olaf.rogalsky <at> gmail.com, 69915 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org> Subject: Re: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Thu, 04 Apr 2024 09:41:30 -0700
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
Eli Zaretskii <eliz <at> gnu.org>
:Olaf Rogalsky <olaf.rogalsky <at> t-online.de>
:Message #67 received at 69915-done <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Jared Finder <jared <at> finder.org> Cc: olaf.rogalsky <at> gmail.com, rudalics <at> gmx.at, 69915-done <at> debbugs.gnu.org Subject: Re: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Sat, 06 Apr 2024 13:15:36 +0300
> Date: Thu, 04 Apr 2024 09:32:28 -0700 > From: Jared Finder <jared <at> finder.org> > Cc: Eli Zaretskii <eliz <at> gnu.org>, olaf.rogalsky <at> gmail.com, > 69915 <at> 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-gnu-emacs <at> gnu.org
:bug#69915
; Package emacs
.
(Mon, 08 Apr 2024 14:15:02 GMT) Full text and rfc822 format available.Message #70 received at 69915 <at> debbugs.gnu.org (full text, mbox):
From: Olaf Rogalsky <olaf.rogalsky <at> gmail.com> To: 69915 <at> debbugs.gnu.org Subject: Re: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Mon, 08 Apr 2024 16:13:54 +0200
help-debbugs <at> 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
Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org
.
(Tue, 07 May 2024 11:24:06 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.