From unknown Thu Aug 14 21:43:06 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#28620 <28620@debbugs.gnu.org> To: bug#28620 <28620@debbugs.gnu.org> Subject: Status: Mouse drag event records wrong window for release when crossing frames Reply-To: bug#28620 <28620@debbugs.gnu.org> Date: Fri, 15 Aug 2025 04:43:06 +0000 retitle 28620 Mouse drag event records wrong window for release when crossi= ng frames reassign 28620 emacs submitter 28620 rswgnu@gmail.com severity 28620 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 27 11:44:53 2017 Received: (at submit) by debbugs.gnu.org; 27 Sep 2017 15:44:53 +0000 Received: from localhost ([127.0.0.1]:35172 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dxEW4-0001Eo-RW for submit@debbugs.gnu.org; Wed, 27 Sep 2017 11:44:53 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49983) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dxEW3-0001EQ-7V for submit@debbugs.gnu.org; Wed, 27 Sep 2017 11:44:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dxEVw-0007GL-5G for submit@debbugs.gnu.org; Wed, 27 Sep 2017 11:44:46 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE, RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:51377) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dxEVw-0007Fx-0c for submit@debbugs.gnu.org; Wed, 27 Sep 2017 11:44:44 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40953) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxEVt-0001Az-Lc for bug-gnu-emacs@gnu.org; Wed, 27 Sep 2017 11:44:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dxEVq-00077b-8O for bug-gnu-emacs@gnu.org; Wed, 27 Sep 2017 11:44:41 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54722) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxEVq-00077P-3U for bug-gnu-emacs@gnu.org; Wed, 27 Sep 2017 11:44:38 -0400 Received: from mail-qk0-f177.google.com ([209.85.220.177]:48562) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1dxEVp-0004OQ-Qg for bug-gnu-emacs@gnu.org; Wed, 27 Sep 2017 11:44:37 -0400 Received: by mail-qk0-f177.google.com with SMTP id a128so13718886qkc.5 for ; Wed, 27 Sep 2017 08:44:37 -0700 (PDT) X-Gm-Message-State: AHPjjUjrCFLRQBBpujFdJRHn1zRWB/I/rznRKm3joFyLI4Do3HoZHJJl YCKcLCDvUUY5QdWDEGE8fz5lSpcQIAGMqjkX1yQ= X-Google-Smtp-Source: AOwi7QA1zoLoYdmlHExYutYIz3hj5XgGCe8h/qCzynYxo7zTYdJ0ZO9vT2dMU/tTBsa1SuVHffNHm0VeULQWpZg8cO4= X-Received: by 10.55.19.228 with SMTP id 97mr1816371qkt.271.1506527077064; Wed, 27 Sep 2017 08:44:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.28.3 with HTTP; Wed, 27 Sep 2017 08:44:06 -0700 (PDT) From: Robert Weiner Date: Wed, 27 Sep 2017 11:44:06 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Mouse drag event records wrong window for release when crossing frames To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary="001a113fe9f045e485055a2dab4b" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rswgnu@gmail.com Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.5 (----) --001a113fe9f045e485055a2dab4b Content-Type: text/plain; charset="UTF-8" With Emacs 25.3 under MacOS 10.12, a drag with mouse-1 depressed from the text area of frame F1 to the text area of frame F2 improperly generates a drag event whose (posn-window (event-end )) shows F1 rather than F2. Note that for a drag between frames, posn-window should return a frame (according to the Elisp manual but not its own doc string). The bug is that the event itself records the wrong frame (the depress frame rather than the release frame). I have confirmed this with Emacs 25.2 under Windows 7 as well. Bob In GNU Emacs 25.3.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1911)) of 2017-09-12 built on builder10-9.local Windowing system distributor 'Apple', version 10.3.1504 Configured using: 'configure --with-ns '--enable-locallisppath=/Library/Application Support/Emacs/${version}/site-lisp:/Library/Application Support/Emacs/site-lisp' --with-modules' Configured features: NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Emacs-Lisp Minor modes in effect: recentf-mode: t shell-dirtrack-mode: t diff-auto-refine-mode: t desktop-save-mode: t winner-mode: t which-key-mode: t show-paren-mode: t which-function-mode: t persistent-scratch-autosave-mode: t paredit-everywhere-mode: t dynamic-completion-mode: t global-edit-server-edit-mode: t delete-selection-mode: t auto-compile-on-load-mode: t auto-compile-on-save-mode: t auto-compile-mode: t outline-minor-mode: t minibuffer-depth-indicate-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-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 auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t auto-fill-function: do-auto-fill transient-mark-mode: t Features: (shadow mail-extr emacsbug tabify man magit-utils crm pulse glasses cus-start cus-load mule-diag ispell filecache two-column iso-transl debug recentf tree-widget helm-x-files helm-for-files helm-bookmark helm-adaptive helm-info bookmark helm-external helm-net helm-files image-dired ffap helm-tags helm-locate tramp tramp-compat tramp-loaddefs trampver eieio-opt speedbar sb-image ezimage dframe helm-buffers helm-grep helm-regexp helm-utils helm-help helm-types thai-util thai-word misearch multi-isearch pcmpl-unix pcmpl-gnu shell dired-aux grep hywconfig network-stream nsm starttls web-beautify org-element org-rmail org-mhe org-irc org-info org-gnus org-docview org-bibtex bibtex org-bbdb org-w3m doc-view arc-mode archive-mode eww mm-url gnus gnus-ems nnheader wid-edit url-queue shr dom texinfo make-mode skewer-html markdown-mode color sh-script smie executable rst conf-mode tern-auto-complete tern jsdock helm-dash cursor-sensor image-mode flycheck rx flymake jedi auto-complete popup jedi-core python-environment epc ctable concurrent deferred pydock pydoc goto-addr autorevert filenotify vc-git diff-mode .emacs desktop frameset window-jump winner which-key supercite regi sort skewer-setup skewer-mode cache-table js2-mode js cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs simple-httpd pp json map python-mode compile thingatpt aggressive-indent paren which-func imenu persistent-scratch js-lookup paredit-everywhere paredit-menu paredit par-align rep-region id-edit wrect rect id-linecol bw-tags apropos file-hdr lib site-key site-func id-keys id-vers chrome-macos emmet-mode dired-x completion ido server edit-server delsel jka-compr auto-compile packed dash hmouse-tag etags xref project rsw-helm helm-easymenu helm edmacro kmacro helm-source eieio-compat helm-multi-match helm-lib wdired async hyperbole hinit hibtypes hib-doc-id hsys-www klink subr-x hib-kbd hib-social hib-debbugs debbugs-gnu debbugs soap-client url-http tls gnutls url-auth url-gw warnings rng-xsd rng-dt rng-util xsd-regexp hsys-org org org-macro org-footnote org-pcomplete pcomplete org-list org-faces org-entities org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp org-src ob-keys ob-comint ob-core ob-eval org-compat org-macs org-loaddefs find-func hactypes comint ansi-color hui-mini hui hui-mouse hui-window hargs hui-menu hyrolo-menu hyrolo google-contacts xml url-cache url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf mailcap url-util url-parse auth-source cl-seq eieio url-vars google-oauth hmail hui-jmenu noutline outline easy-mmode hmouse-key hmouse-sh hmouse-drv hypb locate hsettings hui-em-but hbut hact hpath hhist hbdata htz cal-julian cal-menu calendar cal-loaddefs hbmap hmoccur derived browse-url hui-select web-mode disp-table sgml-mode hvar set hversion hload-path package-x mail-hist sendmail ring message dired format-spec rfc822 mml mml-sec password-cache epg gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mailabbrev mail-utils gmm-utils mailheader rsw-evernote epic htmlize cl add-log exec-path-from-shell finder-inf eieio-core cl-macs kotl-loaddefs pydoc-info advice info-look info package epg-config seq byte-opt gv bytecomp byte-compile cl-extra help-mode cconv mb-depth edebug easymenu cl-loaddefs pcase cl-lib time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel ns-win ucs-normalize term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cl-generic 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 charscript case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote kqueue cocoa ns multi-tty make-network-process emacs) Memory information: ((conses 16 1208296 206512) (symbols 48 87755 1) (miscs 40 9963 6750) (strings 32 234897 19520) (string-bytes 1 7230712) (vectors 16 99432) (vector-slots 8 2323157 242912) (floats 8 1648 1850) (intervals 56 53652 6347) (buffers 976 433)) --001a113fe9f045e485055a2dab4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= With Emacs 25.3 under MacOS= 10.12, a drag with mouse-1 depressed from
the text area of frame F1 = to the text area of frame F2 improperly
generates=C2=A0a drag event whose (posn-window (event= -end <event>)) shows
F1 rather than F2.

Note t= hat for a drag between frames, posn-window should return a frame
(accordi= ng to the Elisp manual but not its own doc string).=C2=A0 The bug is=
that= the event itself records the wrong frame (the depress frame rather<= /div>
than = the release frame).

I have confirmed this with Emacs 25.2 under Wi= ndows 7 as well.

Bob


In GNU Emacs 25.3.1 (x86_64-a= pple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1911))=
=C2= =A0of 2017-09-12 built on builder10-9.local
Windowing system distributor = 'Apple', version 10.3.1504
Configured using:
=C2=A0'configu= re --with-ns '--enable-locallisppath=3D/Library/Application
=C2=A0Sup= port/Emacs/${version}/site-lisp:/Library/Application
=C2=A0Support/Emacs/= site-lisp' --with-modules'

Configured features:
NOTIFY A= CL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES

Important se= ttings:
=C2=A0 value of $LANG: en_US.UTF-8
=C2=A0 locale-coding-system:= utf-8-unix

Major mode: Emacs-Lisp

Minor modes in effec= t:
=C2=A0 recentf-mode: t
=C2=A0 shell-dirtrack-mode: t
=C2=A0 diff-a= uto-refine-mode: t
=C2=A0 desktop-save-mode: t
=C2=A0 winner-mode: t
= =C2=A0 which-key-mode: t
=C2=A0 show-paren-mode: t
=C2=A0 which-functio= n-mode: t
=C2=A0 persistent-scratch-autosave-mode: t
=C2=A0 paredit-eve= rywhere-mode: t
=C2=A0 dynamic-completion-mode: t
=C2=A0 global-edit-s= erver-edit-mode: t
=C2=A0 delete-selection-mode: t
=C2=A0 auto-compile-= on-load-mode: t
=C2=A0 auto-compile-on-save-mode: t
=C2=A0 auto-compile= -mode: t
=C2=A0 outline-minor-mode: t
=C2=A0 minibuffer-depth-indicate-= mode: t
=C2=A0 tooltip-mode: t
<= font face=3D"monospace, monospace">=C2=A0 global-eldoc-mode: t
=
=C2=A0 eld= oc-mode: t
=C2=A0 electric-indent-mode: t
=C2=A0 mouse-wheel-mode: t
= =C2=A0 menu-bar-mode: t
=C2=A0 file-name-shadow-mode: t
=C2=A0 global-f= ont-lock-mode: t
=C2=A0 font-lock-mode: t
=C2=A0 blink-cursor-mode: t
=C2=A0 auto-composition-mode: t
<= font face=3D"monospace, monospace">=C2=A0 auto-encryption-mode: t
=C2=A0 = auto-compression-mode: t
=C2=A0 column-number-mode: t
=C2=A0 line-numbe= r-mode: t
=C2=A0 auto-fill-function: do-auto-fill
=C2=A0 transient-mar= k-mode: t

Features:
(shadow mail-extr emacsbug tabify man magit-= utils crm pulse glasses
cus-start cus-load mule-diag ispell filecache two= -column iso-transl
debug recentf tree-widget helm-x-files helm-for-files = helm-bookmark
helm-adaptive helm-info bookmark helm-external helm-net hel= m-files
image-dired ffap helm-tags helm-locate tramp tramp-compat tramp-l= oaddefs
trampver eieio-opt speedbar sb-image ezimage dframe helm-buffers<= /font>
thai-wo= rd misearch multi-isearch pcmpl-unix pcmpl-gnu shell dired-aux
=
grep hywco= nfig network-stream nsm starttls web-beautify org-element
org-rmail org-m= he org-irc org-info org-gnus org-docview org-bibtex
bibtex org-bbdb org-= w3m doc-view arc-mode archive-mode eww mm-url gnus
gnus-ems nnheader wi= d-edit url-queue shr dom texinfo make-mode
skewer-html markdown-mode colo= r sh-script smie executable rst conf-mode
tern-auto-complete tern jsdock = helm-dash cursor-sensor image-mode
flycheck rx flymake jedi auto-complete= popup jedi-core
python-environment epc ctable concurrent deferred pydock= pydoc goto-addr
autorevert filenotify vc-git diff-mode .emacs desktop fr= ameset
window-jump winner which-key supercite regi sort skewer-setup
sk= ewer-mode cache-table js2-mode js cc-mode cc-fonts cc-guess cc-menus=
cc-c= mds cc-styles cc-align cc-engine cc-vars cc-defs simple-httpd pp
json map= python-mode compile thingatpt aggressive-indent paren
which-func imenu p= ersistent-scratch js-lookup paredit-everywhere
paredit-menu paredit par-a= lign rep-region id-edit wrect rect id-linecol
bw-tags apropos file-hdr li= b site-key site-func id-keys id-vers
chrome-macos emmet-mode dired-x comp= letion ido server edit-server delsel
jka-compr auto-compile packed dash h= mouse-tag etags xref project
rsw-helm helm-easymenu helm edmacro kmacro h= elm-source eieio-compat
helm-multi-match helm-lib wdired async hyperbole = hinit hibtypes
hib-doc-id hsys-www klink subr-x hib-kbd hib-social hib-de= bbugs
debbugs-gnu debbugs soap-client url-http tls gnutls url-auth url-gw=
warnings rng-xsd rng-dt rng-util xsd-regexp hsys-org org org-macro
org= -footnote org-pcomplete pcomplete org-list org-faces org-entities
org-ver= sion ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp
<= div class=3D"gmail_default">org-src ob-= keys ob-comint ob-core ob-eval org-compat org-macs
org-loaddefs find-fu= nc hactypes comint ansi-color hui-mini hui hui-mouse
hui-window hargs hui= -menu hyrolo-menu hyrolo google-contacts xml
url-cache url url-proxy url-= privacy url-expand url-methods url-history
url-cookie url-domsuf mailcap = url-util url-parse auth-source cl-seq
eieio url-vars google-oauth hmail h= ui-jmenu noutline outline easy-mmode
hmouse-key hmouse-sh hmouse-drv hypb= locate hsettings hui-em-but hbut
= hact hpath hhist hbdata htz cal-julian = cal-menu calendar cal-loaddefs
hbmap hmoccur derived browse-url hui-selec= t web-mode disp-table
sgml-mode hvar set hversion hload-path package-x = mail-hist sendmail ring
message dired format-spec rfc822 mml mml-sec pass= word-cache epg
gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231= rfc2047
rfc2045 ietf-drums mm-util help-fns mail-prsvr mailabbrev mail-u= tils
gmm-utils mailheader rsw-evernote epic htmlize cl add-log
exec-pat= h-from-shell finder-inf eieio-core cl-macs kotl-loaddefs
pydoc-info advic= e info-look info package epg-config seq byte-opt gv
bytecomp byte-compil= e cl-extra help-mode cconv mb-depth edebug easymenu
cl-loaddefs pcase cl= -lib time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-ho= oks lisp-float-type mwheel ns-win ucs-normalize
term/common-win tool-bar = dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode = lisp-mode prog-mode register page
= menu-bar rfn-eshadow timer select scrol= l-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic= cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao = korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech europ= ean ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-c= mpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs butt= on faces
cus-face macroexp files text-properties overlay sha1 md5 base64 = format
env code-pages mule custom widget hashtable-print-readable backquo= te
kqueue cocoa ns multi-tty make-network-process emacs)

Memory = information:
((conses 16 1208296 206512)
=C2=A0(symbols 48 87755 1)
= =C2=A0(miscs 40 9963 6750)
=C2=A0(strings 32 234897 19520)
=C2=A0(strin= g-bytes 1 7230712)
=C2=A0(vectors 16 99432)
=C2=A0(vector-slots 8 23231= 57 242912)
=C2=A0(floats 8 1648 1850)
=C2=A0(intervals 56 53652 6347)
=C2=A0(buffers 976 433))

--001a113fe9f045e485055a2dab4b-- From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 30 17:57:30 2017 Received: (at 28620) by debbugs.gnu.org; 30 Sep 2017 21:57:30 +0000 Received: from localhost ([127.0.0.1]:41549 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dyPlJ-0001b7-Ln for submit@debbugs.gnu.org; Sat, 30 Sep 2017 17:57:29 -0400 Received: from eggs.gnu.org ([208.118.235.92]:48178) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dyPlH-0001as-HC for 28620@debbugs.gnu.org; Sat, 30 Sep 2017 17:57:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dyPl9-0001jO-5s for 28620@debbugs.gnu.org; Sat, 30 Sep 2017 17:57:22 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE, RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41070) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dyPl9-0001iy-14 for 28620@debbugs.gnu.org; Sat, 30 Sep 2017 17:57:19 -0400 Received: from mail-qt0-f176.google.com ([209.85.216.176]:50383) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1dyPl8-0001UG-L5 for 28620@debbugs.gnu.org; Sat, 30 Sep 2017 17:57:18 -0400 Received: by mail-qt0-f176.google.com with SMTP id f15so3450242qtf.7 for <28620@debbugs.gnu.org>; Sat, 30 Sep 2017 14:57:18 -0700 (PDT) X-Gm-Message-State: AMCzsaVkHyq6K6wkJHLjynTgyhwOGWKZSnsGnoXPiPO2MHe+RY1DBs/e G+ZIa0ccKe4FY0mFAXGOkOavfykjb4lbb7DH1iA= X-Google-Smtp-Source: AOwi7QDjUnSXQV+VZY527/oCnNiYlxjyGtUrjzbhEeD+x7U+h/fqdsHAX0IOYeUoCJn7ozuc8z/RlLWSlbhqpZFsXv4= X-Received: by 10.237.39.219 with SMTP id m27mr12532296qtg.34.1506808638051; Sat, 30 Sep 2017 14:57:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.34.225 with HTTP; Sat, 30 Sep 2017 14:56:47 -0700 (PDT) In-Reply-To: <59CFD083.40407@gmx.at> References: <83k20h5m2x.fsf@gnu.org> <59CF56AF.3090008@gmx.at> <59CFD083.40407@gmx.at> From: Robert Weiner Date: Sat, 30 Sep 2017 17:56:47 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: bug#28621: Proposed patch for doc of posn-window and code of posn-set-point to handle frame arguments To: martin rudalics Content-Type: multipart/alternative; boundary="f403045ee8569d99d7055a6f3978" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 28620 Cc: Eli Zaretskii , 28620@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rswgnu@gmail.com Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.5 (----) --f403045ee8569d99d7055a6f3978 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Sep 30, 2017 at 1:12 PM, martin rudalics wrote: > > This speaks to my point in my most recent prior message, "If we just ha= d > a > > way to get a window from a set of coordinates within a frame, then I > think > > this would help solve a lot of this." If the event-end of Emacs mouse > drag > > events included a window, rather than a frame, when the endpoint of the > > drag is at a position unique to a window (considering Z-frame order), I > > think that would solve all these issues and simplify parts of the posn > code. > =E2=80=8BThe issue, to recap, is that I can't find a function that will report the window that a mouse release button event occurs in if the depress and release are in different frames (for Emacs 25). In fact, the release event (drag event) contains the wrong frame (that of the depress rather than the release). The wrong frame is also reported by mouse-position and mouse-pixel-position, so window-at can't be used either. The problem seems to be documented in the Emacs event design. Frame selection events are deferred when they occur while a button is depressed to prevent some kind of state inconsistency. But as a result, the drag release event records the wrong frame and there is no way for the release binding to determine and record the right one. > Take the position of the event-end (if it's a frame) and translate it > into absolute screen coordinates (the Elisp manual should give you > enough clues to do that). Or, try =E2=80=98mouse-absolute-pixel-position= =E2=80=99 - it > should give you the screen position of the mouse at that time so you can > ignore the event completely. > > Then walk all your windows and compare that position with whatever > =E2=80=98window-absolute-pixel-edges=E2=80=99 returns for that window. I= f you have two > or more positives, run =E2=80=98frame-list-z-order=E2=80=99 and compare t= he result > against those windows' frames. No hands, IMHO. =E2=80=8Bframe-list-z-order is Emacs 26 only; I need something that works w= ith older versions.=E2=80=8B Bob --f403045ee8569d99d7055a6f3978 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Sep 30, 2= 017 at 1:12 PM, martin rudalics <rudalics@gmx.at> wrote:
> This speaks to m= y point in my most recent prior message, "If we just had a
> way to get a window from a set of coordinates within a frame, then I t= hink
> this would help solve a lot of this."=C2=A0 If the event-end of E= macs mouse drag
> events included a window, rather than a frame, when the endpoint of th= e
> drag is at a position unique to a window (considering Z-frame order), = I
> think that would solve all these issues and simplify parts of the posn= code.

=E2=80=8BThe issue, to recap, is t= hat I can't find a function that
will report the window that a mouse r= elease button event
occurs in if the depress and release are in different = frames
(for Emacs 25).

In fact, the release event (drag event) cont= ains the wrong
frame (that of the depress rather than the release).=C2=A0 = The wrong=C2=A0
frame is also reported by mouse-position and mouse-pixel-p= osition,
so window-at can't be used either.

The problem seems t= o be documented in the Emacs event design.
Frame selection events are defe= rred when they occur while a button
is depressed to prevent some kind of s= tate inconsistency.=C2=A0 But as
a result, the drag release event records = the wrong frame and there
is no way for the release binding to determine a= nd record the right
one.


 Take the position of the event-end (if it's a frame) and translate it into absolute screen coordinates (the Elisp manual should give you
enough clues to do that).=C2=A0 Or, try =E2=80=98mouse-absolute-pixel-posit= ion=E2=80=99 - it
should give you the screen position of the mouse at that time so you can ignore the event completely.

Then walk all your windows and compare that position with whatever
=E2=80=98window-absolute-pixel-edges=E2=80=99 returns for that window.=C2= =A0 If you have two
or more positives, run =E2=80=98frame-list-z-order=E2=80=99 and compare the= result
against those windows' frames.=C2=A0 No hands, IMHO.
<= br>
=E2=80=8Bframe-list-z-order is Emacs 26 only; I need something that wo= rks with older versions.=E2=80=8B

Bob


<= /div> --f403045ee8569d99d7055a6f3978-- From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 30 19:35:34 2017 Received: (at 28620) by debbugs.gnu.org; 30 Sep 2017 23:35:34 +0000 Received: from localhost ([127.0.0.1]:41606 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dyRID-0006Ho-V9 for submit@debbugs.gnu.org; Sat, 30 Sep 2017 19:35:34 -0400 Received: from eggs.gnu.org ([208.118.235.92]:39637) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dyRIC-0006HZ-6C for 28620@debbugs.gnu.org; Sat, 30 Sep 2017 19:35:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dyRI4-00066A-AN for 28620@debbugs.gnu.org; Sat, 30 Sep 2017 19:35:27 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,HTML_MESSAGE, RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54211) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dyRI4-00065P-7E for 28620@debbugs.gnu.org; Sat, 30 Sep 2017 19:35:24 -0400 Received: from mail-qt0-f177.google.com ([209.85.216.177]:52782) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1dyRI3-0002Fu-QR for 28620@debbugs.gnu.org; Sat, 30 Sep 2017 19:35:24 -0400 Received: by mail-qt0-f177.google.com with SMTP id o52so3552935qtc.9 for <28620@debbugs.gnu.org>; Sat, 30 Sep 2017 16:35:23 -0700 (PDT) X-Gm-Message-State: AMCzsaW/q+5Njd5haRqGkXVXeL0jWb4XzvXPde8DJ+/mRp+Cii+r+8G1 qzg009wofd2PzC2ubXwuSX16USloBwrhvetSftI= X-Google-Smtp-Source: AOwi7QB0qVQSMqWxzu9MxtVOE5obbSHHs6pWpsz4/X8CKYOizZuYGICtqrg7tU/nuIzaJ4qULLFas7z4SraEQMvm8s0= X-Received: by 10.200.54.3 with SMTP id m3mr13206148qtb.197.1506814523252; Sat, 30 Sep 2017 16:35:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.34.225 with HTTP; Sat, 30 Sep 2017 16:34:52 -0700 (PDT) In-Reply-To: References: <83k20h5m2x.fsf@gnu.org> <59CF56AF.3090008@gmx.at> <59CFD083.40407@gmx.at> From: Robert Weiner Date: Sat, 30 Sep 2017 19:34:52 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: bug#28621: Proposed patch for doc of posn-window and code of posn-set-point to handle frame arguments To: martin rudalics Content-Type: multipart/alternative; boundary="001a1137b05466a8f7055a70982f" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 28620 Cc: Eli Zaretskii , 28620@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rswgnu@gmail.com Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) --001a1137b05466a8f7055a70982f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Sep 30, 2017 at 5:56 PM, Robert Weiner wrote: > In fact, the release event (drag event) contains the wrong > frame (that of the depress rather than the release). > =E2=80=8BIn looking at how mouse-1 is able to select the proper window of a= mouse click, I found that the release binding of mouse-1 changes when a click is in a frame other than the selected one. In that case, it shifts from mouse-set-point to handle-switch-frame which selects the new frame. Is this shift due to the transient-map map setting in mouse-drag-track? Eli, if you could point me to where the switch-frame event is generated when the click is in another frame, with that I might be able to produce a temporary fix for this problem. It would also help if in handle-switch-frame, the handle-focus-in hook invocation occurred after the call to do_switch_frame rather than before; then we could grab the value of the newly selected frame rather than the old one. Bob tBut I can't find anywhere in the Emacs 25 code where mouse-1 is bound to handle-switch-frame. Can you point me to where this is coded? Is the keymap in use changing? Is there any way to capture a switch-frame event and attach my own handler to it? (I guess I could redefine the primitive handle-switch-fraem --001a1137b05466a8f7055a70982f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Sep 30, 2= 017 at 5:56 PM, Robert Weiner <rsw= @gnu.org> wrote:=
In fact, the release event (drag event) contains the = wrong
frame (that of the depress = rather than the release).

= =E2=80=8BIn looking at how mouse-1 is able to select the proper window of a= mouse click,
I found that the release binding of mouse-1 changes when a c= lick is in a frame
other than the selected one.=C2=A0 In that case, it shi= fts from mouse-set-point to
handle-switch-frame which selects the new fram= e.=C2=A0 Is this shift due to the transient-map
map setting in mouse-drag-= track?

Eli, if you could point me to where the switch-frame event is= generated when the click
is in another frame, with that I might be able t= o produce a temporary fix for this problem.

It would also help if in= handle-switch-frame, the handle-focus-in hook invocation occurred
after t= he call to do_switch_frame rather than before; then we could grab the value= of the
newly selected frame rather than the old one.

Bob

tBut I can't find anywhere in
the Emacs 25 code where mouse-1 is b= ound to handle-switch-frame.

Can you point me to where this is code= d?=C2=A0 Is the keymap in use changing?
Is there any way to capture a swit= ch-frame event and attach my own handler to
it?=C2=A0 (I guess I could red= efine the primitive handle-switch-fraem
=C2=A0
--001a1137b05466a8f7055a70982f-- From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 03 14:22:25 2017 Received: (at 28620) by debbugs.gnu.org; 3 Oct 2017 18:22:25 +0000 Received: from localhost ([127.0.0.1]:46736 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzRpp-0004ce-93 for submit@debbugs.gnu.org; Tue, 03 Oct 2017 14:22:25 -0400 Received: from eggs.gnu.org ([208.118.235.92]:56350) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzRpn-0004cP-M2 for 28620@debbugs.gnu.org; Tue, 03 Oct 2017 14:22:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzRpf-0007N7-7M for 28620@debbugs.gnu.org; Tue, 03 Oct 2017 14:22:18 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE, RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38416) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzRpf-0007Ms-45 for 28620@debbugs.gnu.org; Tue, 03 Oct 2017 14:22:15 -0400 Received: from mail-qt0-f178.google.com ([209.85.216.178]:52993) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1dzRpe-00031w-SX for 28620@debbugs.gnu.org; Tue, 03 Oct 2017 14:22:15 -0400 Received: by mail-qt0-f178.google.com with SMTP id o52so14641027qtc.9 for <28620@debbugs.gnu.org>; Tue, 03 Oct 2017 11:22:14 -0700 (PDT) X-Gm-Message-State: AMCzsaWS7JcrTMwnQ/ps6rWVRkMu4vm/0hKpKHH6obwKHRjNlrLE3Iit 713L/Z2N3cT8Muf7K/L4lMzI1XBHwoCyIF2Wsts= X-Google-Smtp-Source: AOwi7QC2rhJqDo5vahh4K98cqVtZzNDTgFonrH1d90s7n5iIo/ND4xA12WOm/LrP3+XebtaPqP0kw38IsdYRLKwlZGo= X-Received: by 10.200.54.3 with SMTP id m3mr842794qtb.197.1507054934286; Tue, 03 Oct 2017 11:22:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.34.225 with HTTP; Tue, 3 Oct 2017 11:21:43 -0700 (PDT) In-Reply-To: References: <83wp4e3nvx.fsf@gnu.org> <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> From: Robert Weiner Date: Tue, 3 Oct 2017 14:21:43 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records wrong release window To: 28620@debbugs.gnu.org Content-Type: multipart/alternative; boundary="001a1137b05403ea3c055aa892a9" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 28620 Cc: Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rswgnu@gmail.com Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.5 (----) --001a1137b05403ea3c055aa892a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Using the latest Emacs26 built from master on MacOS Sierra using the macOS window system, I see the following if I have two frames: f1 and f2. I start with the mouse within a window of f1 and selected frame of f1; (mouse-position) also reports f1. I click mouse-1 in an Emacs window of f2 and leave it there. (selected-frame) is now f2 macOS window manager highlights f2 as active window (frame-focus) returns nil (mouse-position) reports a frame of f1 <<< WRONG I click mouse-1 again in the same Emacs window of f2. (selected-frame) is still f2 macOS window manager highlights f2 as active window (frame-focus) returns nil (mouse-position) now reports a frame of f2 This happens consistently in testing. This must be a bug in mouse-position for macOS, right? Why would (mouse-position) still report f1 when f2 is the selected frame? Maybe this is why I am seeing the wrong frame on drag releases too. If anyone else could confirm this and whether it happens on other window systems that use a mouse click to select windows, that would be helpful. Bob =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8B --001a1137b05403ea3c055aa892a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Using the latest Emacs26 built from master on MacOS Sierra usi= ng the macOS window system, I see the following if I have two frames: f1 an= d f2.

I start with the mouse within a window of f1 and selected fram= e of f1; (mouse-position) also reports f1.

I click mouse-1 in an Ema= cs window of f2 and leave it there.
=C2=A0 (selected-frame) is now f2
=C2= =A0 macOS window manager highlights f2 as active window
=C2=A0 (frame-focu= s) returns nil
=C2=A0 (mouse-position) reports a frame of f1=C2=A0 =C2=A0 = =C2=A0 =C2=A0<<< WRONG


I click mouse-1 again in the s= ame Emacs window of f2.
=C2=A0 (selected-frame) is still f2
=C2=A0 macOS = window manager highlights f2 as active window
=C2=A0 (frame-focus) returns= nil
=C2=A0 (mouse-position) now reports a frame of f2

This happens= consistently in testing.=C2=A0 This must be a bug in mouse-position for ma= cOS, right?=C2=A0 Why would (mouse-position) still report f1 when f2 is the= selected frame?=C2=A0 Maybe this is why I am seeing the wrong frame on dra= g releases too.

If anyone else could confirm this and whether it hap= pens on other window systems that use a mouse click to select windows, that= would be helpful.

Bob

=E2=80=8B= =E2=80=8B
=E2=80=8B=E2=80=8B


--001a1137b05403ea3c055aa892a9-- From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 03 14:43:30 2017 Received: (at 28620) by debbugs.gnu.org; 3 Oct 2017 18:43:30 +0000 Received: from localhost ([127.0.0.1]:46757 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzSAE-0005EH-Ds for submit@debbugs.gnu.org; Tue, 03 Oct 2017 14:43:30 -0400 Received: from eggs.gnu.org ([208.118.235.92]:38764) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzSAB-0005E3-Dy for 28620@debbugs.gnu.org; Tue, 03 Oct 2017 14:43:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzSA1-0000l0-TY for 28620@debbugs.gnu.org; Tue, 03 Oct 2017 14:43:22 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39011) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzSA1-0000k7-Jv; Tue, 03 Oct 2017 14:43:17 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3134 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dzS9z-00034N-UA; Tue, 03 Oct 2017 14:43:17 -0400 Date: Tue, 03 Oct 2017 21:42:53 +0300 Message-Id: <83r2ukyswj.fsf@gnu.org> From: Eli Zaretskii To: rswgnu@gmail.com In-reply-to: (message from Robert Weiner on Tue, 3 Oct 2017 14:21:43 -0400) Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records wrong release window References: <83wp4e3nvx.fsf@gnu.org> <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 28620 Cc: 28620@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Robert Weiner > Date: Tue, 3 Oct 2017 14:21:43 -0400 > Cc: Eli Zaretskii > > I start with the mouse within a window of f1 and selected frame of f1; (mouse-position) also reports f1. > > I click mouse-1 in an Emacs window of f2 and leave it there. > (selected-frame) is now f2 > macOS window manager highlights f2 as active window > (frame-focus) returns nil > (mouse-position) reports a frame of f1 <<< WRONG Sounds like something that's macOS specific. At least on MS-Windows I cannot reproduce this: mouse-position returns the correct frame. From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 03 14:53:51 2017 Received: (at 28620) by debbugs.gnu.org; 3 Oct 2017 18:53:51 +0000 Received: from localhost ([127.0.0.1]:46767 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzSKF-0005Vj-CW for submit@debbugs.gnu.org; Tue, 03 Oct 2017 14:53:51 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41737) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzSKD-0005VU-MS for 28620@debbugs.gnu.org; Tue, 03 Oct 2017 14:53:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzSK3-0004B0-3x for 28620@debbugs.gnu.org; Tue, 03 Oct 2017 14:53:44 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE, RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39159) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzSK2-0004An-VY for 28620@debbugs.gnu.org; Tue, 03 Oct 2017 14:53:39 -0400 Received: from mail-qk0-f171.google.com ([209.85.220.171]:47112) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1dzSK2-0003f0-Kg for 28620@debbugs.gnu.org; Tue, 03 Oct 2017 14:53:38 -0400 Received: by mail-qk0-f171.google.com with SMTP id m189so5186644qke.4 for <28620@debbugs.gnu.org>; Tue, 03 Oct 2017 11:53:38 -0700 (PDT) X-Gm-Message-State: AMCzsaVEfoy2Y13bLgCorbcuWgOK5FSnjiV9WzsrENp8JwTY4inbtS5I mpzu39rieQXjXBN7Z5tIe+z2JmfVrrGqtgSZO5w= X-Google-Smtp-Source: AOwi7QDwO4JRhoPoYR4As6wyoGS3wVhHF2ZawS5EaHH5YbfdW1bzissySIBF+9cUYxDW28Mq05HAO3BmLsFWwulWs4s= X-Received: by 10.55.12.130 with SMTP id 124mr3163946qkm.186.1507056817995; Tue, 03 Oct 2017 11:53:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.34.225 with HTTP; Tue, 3 Oct 2017 11:53:07 -0700 (PDT) In-Reply-To: <83r2ukyswj.fsf@gnu.org> References: <83wp4e3nvx.fsf@gnu.org> <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <83r2ukyswj.fsf@gnu.org> From: Robert Weiner Date: Tue, 3 Oct 2017 14:53:07 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records wrong release window To: Eli Zaretskii Content-Type: multipart/alternative; boundary="001a114d6da04b0771055aa9026f" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 28620 Cc: 28620@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rswgnu@gmail.com Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.5 (----) --001a114d6da04b0771055aa9026f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 3, 2017 at 2:42 PM, Eli Zaretskii wrote: > > From: Robert Weiner > > Date: Tue, 3 Oct 2017 14:21:43 -0400 > > Cc: Eli Zaretskii > > > > I start with the mouse within a window of f1 and selected frame of f1; > (mouse-position) also reports f1. > > > > I click mouse-1 in an Emacs window of f2 and leave it there. > > (selected-frame) is now f2 > > macOS window manager highlights f2 as active window > > (frame-focus) returns nil > > (mouse-position) reports a frame of f1 <<< WRONG > > Sounds like something that's macOS specific. At least on MS-Windows I > cannot reproduce this: mouse-position returns the correct frame. > =E2=80=8BOk, that is good to know. Is there a go to person for the Mac-spe= cific windowing code to check on this with? Could someone check when running X with a click-for-focus window manager setting and see what happens there? Bob --001a114d6da04b0771055aa9026f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Oct 3, 20= 17 at 2:42 PM, Eli Zaretskii <eli= z@gnu.org> wrote= :
> From: Robert Weiner <rsw@gnu.org>
> Date: Tue, 3 Oct 2017 14:21:43 -0400
> Cc: Eli Zaretskii <eliz@gnu.org= >
>
> I start with the mouse within a window of f1 and selected frame of f1;= (mouse-position) also reports f1.
>
> I click mouse-1 in an Emacs window of f2 and leave it there.
> (selected-frame) is now f2
> macOS window manager highlights f2 as active window
> (frame-focus) returns nil
> (mouse-position) reports a frame of f1 <<< WRONG

Sounds like something that's macOS specific.=C2=A0 At least on M= S-Windows I
cannot reproduce this: mouse-position returns the correct frame.

=E2=80=8BOk, that is good to know.=C2=A0 Is there a go to = person for the Mac-specific windowing code to check on this with?

Co= uld someone check when running X with a click-for-focus window manager sett= ing and see what happens there?

Bob


--001a114d6da04b0771055aa9026f-- From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 03 16:55:05 2017 Received: (at 28620) by debbugs.gnu.org; 3 Oct 2017 20:55:05 +0000 Received: from localhost ([127.0.0.1]:46901 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzUDZ-0000M4-G3 for submit@debbugs.gnu.org; Tue, 03 Oct 2017 16:55:05 -0400 Received: from eggs.gnu.org ([208.118.235.92]:40849) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzUDX-0000LX-W3 for 28620@debbugs.gnu.org; Tue, 03 Oct 2017 16:55:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzUDO-0004PX-2z for 28620@debbugs.gnu.org; Tue, 03 Oct 2017 16:54:58 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE, RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41922) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzUDN-0004PM-VW for 28620@debbugs.gnu.org; Tue, 03 Oct 2017 16:54:54 -0400 Received: from mail-qt0-f177.google.com ([209.85.216.177]:44062) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1dzUDN-0004ho-MB for 28620@debbugs.gnu.org; Tue, 03 Oct 2017 16:54:53 -0400 Received: by mail-qt0-f177.google.com with SMTP id v28so6688957qtv.1 for <28620@debbugs.gnu.org>; Tue, 03 Oct 2017 13:54:53 -0700 (PDT) X-Gm-Message-State: AMCzsaVScejS584oJjAeE7BwaqEO+0rSqMw5r/WCfMSt5bmyPpPsxs89 cuX/DOgvRCxwXVvhzEdu6kuRr3qqzE4p1zjl9qk= X-Google-Smtp-Source: AOwi7QCwyzryKrivLyEDoD6pUNsuM7oxsAzOg33YXhFtqv1JFf5MI/fvZCvxTPyeXfxEanQEekPPWf3qJaiXGbUZZ4E= X-Received: by 10.200.57.29 with SMTP id s29mr26327388qtb.309.1507064093197; Tue, 03 Oct 2017 13:54:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.34.225 with HTTP; Tue, 3 Oct 2017 13:54:22 -0700 (PDT) From: Robert Weiner Date: Tue, 3 Oct 2017 16:54:22 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: (mouse-position_ wrong on macOS after mouse-1 click (Was: Interact directly on Emacs bug#28620: mouse drag event records wrong release window) To: 28620@debbugs.gnu.org Content-Type: multipart/alternative; boundary="001a11418c4eedcb82055aaab375" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 28620 Cc: Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rswgnu@gmail.com Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.5 (----) --001a11418c4eedcb82055aaab375 Content-Type: text/plain; charset="UTF-8" Interestingly, mouse wheel scroll events work properly. Such events always include the window the mouse is over (when mouse-wheel-follow-mouse is t, which it is by default). They select this window and then scroll that window, so I can move the mouse across frames and scroll arbitrary windows, which suggests that drag events should operate similarly and include the window of the drag release. Now to find out how the position of the mouse is used differently in mouse drags compared to mouse wheel events. Bob --001a11418c4eedcb82055aaab375 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Interestingly, mouse wheel scroll events work properly.=C2=A0 = Such events always include the window the mouse is over (when mouse-wheel-f= ollow-mouse is t, which it is by default).=C2=A0 They select this window an= d then scroll that window, so I can move the mouse across frames and scroll= arbitrary windows, which suggests that drag events should operate similarl= y and include the window of the drag release.

Now to find out how th= e position of the mouse is used differently in mouse drags compared to mous= e wheel events.

Bob

--001a11418c4eedcb82055aaab375-- From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 03 18:40:30 2017 Received: (at 28620) by debbugs.gnu.org; 3 Oct 2017 22:40:30 +0000 Received: from localhost ([127.0.0.1]:46972 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzVra-00032b-EB for submit@debbugs.gnu.org; Tue, 03 Oct 2017 18:40:30 -0400 Received: from mail-wm0-f51.google.com ([74.125.82.51]:43947) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzVrX-00032M-Ue for 28620@debbugs.gnu.org; Tue, 03 Oct 2017 18:40:28 -0400 Received: by mail-wm0-f51.google.com with SMTP id m72so12457033wmc.0 for <28620@debbugs.gnu.org>; Tue, 03 Oct 2017 15:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=zekWL6hXKyb4s51tVE22ZXVEpXfvCiT4EkQSDsnjD14=; b=vPivADS6BzGUCR6SAYi17ggUu6PY8yVuI0nemfaz27iWgByhahgR9Aee9ZIBkeM1by ed4IvvJkOyXGzwt+UfF02upHv0O6kgCoXsCMIflpOKBGqUORJtPY61J59sNO2XBuQUlJ M75FZXnlHotLnGCpsMOGEo8DVsk7MjHwMXBcfFDsTA5odGj1ShPFElqwzhGspbPmtzlg 7a1I6X6hctEIF/lQdbTtHOJN1mpvKt0cBK7/OiETyYZl/UTo1WyBZwqlyzkS7DRRXfMt g7IcVv3Vh+cQIBPOvYYIY2oM5X2cBKlkZfMx5+RIP9CeyTBMHcNqj0WzV3tmGggxYNfT pL+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=zekWL6hXKyb4s51tVE22ZXVEpXfvCiT4EkQSDsnjD14=; b=Ohevb0rvJBgSXMzTW1gEr5u4cxhYMaQsynl7xzUJWoL3d8pjsiNuqerhq5qYpuJqRY ThOMlxgCBRDyR+ApyhjEmXUqF1O99sRs227L/TxTJ4NbmZmSxVcldzHafklIreILppcD QSh/EuraRUAVicFxK4rLFT6PQOzwNgQf3Xvm5w2/Ntv8wThdfwzpR2Fi9ddj9pXbP8Lz tvJcSYSHX3iHtcVby7Tkb5Vl45qQaVUw031WimFvDyOwRcgqq/Zbs25ohaanMAReA5Z8 YnZ+J1ajyygDw7qy6brLQoznYL6leN5YMCZjduBtDOizZpotpnwYcvNwJIIz/1mPB50b oFPA== X-Gm-Message-State: AMCzsaX3OjtR8FJlNCGqrX6qXvEiTprApEdCslemeYZv8g6CcrVi85HU zrmz2dUMkyndJEROpw/gBt4= X-Google-Smtp-Source: AOwi7QDe79V3MKRnTOXttEnydExFZGI7PBWFIqhjii040S9xfssUcECAoJfYozW0h7IJ1ZYj8KrCNw== X-Received: by 10.28.17.1 with SMTP id 1mr266952wmr.66.1507070420995; Tue, 03 Oct 2017 15:40:20 -0700 (PDT) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-ad89-e054-05c6-3eca.holly.idiocy.org. [2001:8b0:3f8:8129:ad89:e054:5c6:3eca]) by smtp.gmail.com with ESMTPSA id 204sm15841692wml.10.2017.10.03.15.40.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Oct 2017 15:40:19 -0700 (PDT) Date: Tue, 3 Oct 2017 23:40:17 +0100 From: Alan Third To: rswgnu@gmail.com Subject: Re: bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window Message-ID: <20171003224017.GA51637@breton.holly.idiocy.org> References: <83wp4e3nvx.fsf@gnu.org> <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.0 (2017-09-02) X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 28620 Cc: 28620@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) On Tue, Oct 03, 2017 at 02:21:43PM -0400, Robert Weiner wrote: > This happens consistently in testing. This must be a bug in mouse-position > for macOS, right? Why would (mouse-position) still report f1 when f2 is > the selected frame? Maybe this is why I am seeing the wrong frame on drag > releases too. As far as I can tell ns_mouse_position returns the frame stored in dpyinfo->last_mouse_frame, which is set by EmacsView::mouseDown, however: If the user clicks a view that isn’t in the key window, by default the window is brought forward and made key, but the mouse event is not dispatched. https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/EventOverview/HandlingMouseEvents/HandlingMouseEvents.html My guess is that ns_mouse_position needs to get a list of NSWindows, iterate over them to find out which one the mouse pointer is over, convert that NSWindow back to an Emacs frame, and set *fp to it before returning. That way it should return the frame the mouse is over, rather than the last one that received a click event. I’m not sure what happens if the mouse isn’t over an emacs frame... Does it just return *fp unchanged? -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 03 20:16:36 2017 Received: (at 28620) by debbugs.gnu.org; 4 Oct 2017 00:16:37 +0000 Received: from localhost ([127.0.0.1]:47050 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzXMa-00071F-Ik for submit@debbugs.gnu.org; Tue, 03 Oct 2017 20:16:36 -0400 Received: from eggs.gnu.org ([208.118.235.92]:53661) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzXMY-0006vY-SA for 28620@debbugs.gnu.org; Tue, 03 Oct 2017 20:16:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzXMO-00027F-Oz for 28620@debbugs.gnu.org; Tue, 03 Oct 2017 20:16:29 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE, RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46182) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzXMO-00026w-Kv for 28620@debbugs.gnu.org; Tue, 03 Oct 2017 20:16:24 -0400 Received: from mail-qt0-f172.google.com ([209.85.216.172]:48675) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1dzXMO-0006j4-92 for 28620@debbugs.gnu.org; Tue, 03 Oct 2017 20:16:24 -0400 Received: by mail-qt0-f172.google.com with SMTP id d13so15605330qta.5 for <28620@debbugs.gnu.org>; Tue, 03 Oct 2017 17:16:24 -0700 (PDT) X-Gm-Message-State: AMCzsaVKFDhDcjlnLX9Tng8yUTtahOqwo2GahRTn0N41d7UapdPLUZtw QJo401J8jdsMlZjwdRFkPLOcZiowqpPtQxBNUoQ= X-Google-Smtp-Source: AOwi7QCO/kFGH5Om2FJ5lgs9Z6LLA4vHEhxbnytuxIeJN7N4t5/u+17OVQcHq360BXjDfmUsi4xHc5FII2j5jFklTDY= X-Received: by 10.200.34.167 with SMTP id f36mr25633144qta.173.1507076183850; Tue, 03 Oct 2017 17:16:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.34.225 with HTTP; Tue, 3 Oct 2017 17:15:53 -0700 (PDT) In-Reply-To: <20171003224017.GA51637@breton.holly.idiocy.org> References: <83wp4e3nvx.fsf@gnu.org> <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <20171003224017.GA51637@breton.holly.idiocy.org> From: Robert Weiner Date: Tue, 3 Oct 2017 20:15:53 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window To: Alan Third Content-Type: multipart/alternative; boundary="001a11404ff69685c0055aad840b" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 28620 Cc: 28620@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rswgnu@gmail.com Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.5 (----) --001a11404ff69685c0055aad840b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 3, 2017 at 6:40 PM, Alan Third wrote: > On Tue, Oct 03, 2017 at 02:21:43PM -0400, Robert Weiner wrote: > > This happens consistently in testing. This must be a bug in > mouse-position > > for macOS, right? Why would (mouse-position) still report f1 when f2 i= s > > the selected frame? Maybe this is why I am seeing the wrong frame on > drag > > releases too. > > As far as I can tell ns_mouse_position returns the frame stored in > dpyinfo->last_mouse_frame, which is set by EmacsView::mouseDown, however: > > If the user clicks a view that isn=E2=80=99t in the key window, by de= fault > the window is brought forward and made key, but the mouse event is > not dispatched. > =E2=80=8BWhat does "the mouse event is not dispatched mean"? Does it mean = Emacs never sees the event? Maybe Emacs sees only that the window has been selected by the window manager and based on that switches to the selected window of the frame? > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > https://developer.apple.com/library/content/documentation/ > Cocoa/Conceptual/EventOverview/HandlingMouseEvents/ > HandlingMouseEvents.html > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > My guess is that ns_mouse_position needs to get a list of NSWindows, > =E2=80=8B=E2=80=8B > iterate over them to find out which one the mouse pointer is over, > =E2=80=8B=E2=80=8B > convert that NSWindow back to an Emacs frame, and set *fp to it before > =E2=80=8B=E2=80=8B > returning. > =E2=80=8BThe mouse wheel code manages to scroll the proper window that the = mouse is over, even across overlapping frames where the window the mouse is over is in a frame that is partially behind another frame. And this happens without without any click events. This could be utilized in the click event code to get this right somehow. It looks like the EV_TRAILER macro call at the end of the nsterm.c mouseDown function (which is also called by mouseUp) sets the frame used for mouse button down, up and scroll wheel events from the variable emacsframe. Somehow the value of emacsframe must be set differently for mouse up events than it is for mouse wheel events since they end up with different frames for the same mouse positions. Bob --001a11404ff69685c0055aad840b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Oct 3, 20= 17 at 6:40 PM, Alan Third <ala= n@idiocy.org> wr= ote:
=
On Tue, Oct 03, 2017 at 02:21:43PM -0400, Ro= bert Weiner wrote:
> This happens consistently in testing.=C2=A0 This must be a bug in mous= e-position
> for macOS, right?=C2=A0 Why would (mouse-position) still report f1 whe= n f2 is
> the selected frame?=C2=A0 Maybe this is why I am seeing the wrong fram= e on drag
> releases too.

As far as I can tell ns_mouse_position returns the frame stored in
dpyinfo->last_mouse_frame, which is set by EmacsView::mouseDown, however= :

=C2=A0 =C2=A0 If the user clicks a view that isn=E2=80=99t in the key windo= w, by default
=C2=A0 =C2=A0 the window is brought forward and made key, but the mouse eve= nt is
=C2=A0 =C2=A0 not dispatched.

=E2=80=8BWhat does= "the mouse event is not dispatched mean"?=C2=A0 Does it mean Ema= cs never sees the event?=C2=A0 Maybe Emacs sees only that the window has be= en selected by the window manager and based on that switches to the selecte= d window of the frame?
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://developer.apple.com/library/content/docum= entation/Cocoa/Conceptual/EventOverview/HandlingMouseEvents/= HandlingMouseEvents.html
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
My guess is that ns_mouse_position needs= to get a list of NSWindows,
=E2=80=8B=E2=80=8B
iterate over them to find out which one = the mouse pointer is over,
=E2=80=8B=E2=80=8B
convert that NSWindow back to an Emacs f= rame, and set *fp to it before
=E2=80=8B=E2=80=8B
returning.

= =E2=80=8BThe mouse wheel code manages to scroll the proper window that the = mouse is over, even across overlapping frames where the window the mouse is= over is in a frame that is partially behind another frame.=C2=A0 And this = happens without without any click events.=C2=A0 This could be utilized in t= he click event code to get this right somehow.

It looks like the EV_= TRAILER macro call at the end of the nsterm.c mouseDown function (which is = also called by mouseUp) sets the frame used for mouse button down, up and s= croll wheel events from the variable emacsframe.=C2=A0 Somehow the value of= emacsframe must be set differently for mouse up events than it is for mous= e wheel events since they end up with different frames for the same mouse p= ositions.

Bob

--001a11404ff69685c0055aad840b-- From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 04 12:31:00 2017 Received: (at 28620) by debbugs.gnu.org; 4 Oct 2017 16:31:00 +0000 Received: from localhost ([127.0.0.1]:49123 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzmZY-0006Yg-1f for submit@debbugs.gnu.org; Wed, 04 Oct 2017 12:31:00 -0400 Received: from mail-wm0-f45.google.com ([74.125.82.45]:46704) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzmZW-0006YS-ME for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 12:30:59 -0400 Received: by mail-wm0-f45.google.com with SMTP id m72so24054778wmc.1 for <28620@debbugs.gnu.org>; Wed, 04 Oct 2017 09:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=qOH+FYwMKGIfhWJKiiw2IBBwgM/+BWxzVUilNCwgCCs=; b=JFvetoP24BNvxwL0jV5uDmGHQ2FE3ksUTYO16AuzGWmUbI26Ba5fTh5kGlPaiZW3Rz YaQy+ATa+QjHl9Eu4bferHnHY3L3rWkfw4S9ySPD+6RtPah9VT+YR2qls/fjJ0KYnGs6 4vKd6qNVuq+GK0tplXayy1cin2Se4bjTmQkN5dGjbCojqaMmwnMtROHij/SbsDLxlXhs 1C5DyJTMYBdvuB328HF4lGq5iapBGGUNFtyuWT6c1566CBDZ2sd29fkHJeKpDMBfZelV YtnTUZVl2X7wEQK98vCVt0U+Jx3Ylp3d6vphH85J1pN3hnRa+HrHbPjM7oEOSuM3Bp6Q XZVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=qOH+FYwMKGIfhWJKiiw2IBBwgM/+BWxzVUilNCwgCCs=; b=g7rVpHNS1z79zqxYIqf4z86aQU37OEvuZJeJD1ArJE3mynhFer7pCARx19DrVoY4be Xod/liJdNIBmK5nLVY89hDFbS6DF4DLEiHbSXn6lN0iQU+DSY451AQ5o6+/AglOhbLcY 5AHU6pkstpIt3BaAy3mJKcy1XQsBbkgj3oEdQH9IbTO+posTy2HS1vN93g3QuEuzWXEN lYzQ6a/oCaNVl0JE+d/AAqEWmfcVjE+Yy0C3rTcfAi/+QNJrWxCS6WKuMHwyYDfA2FwR 5MUfwmhKlJhnjMGDVVJFetsK4lvVVaSQ/NOTLyJ7aNlNjjDCi+JI21jnlhwlFwBpO0rg cl1A== X-Gm-Message-State: AHPjjUh8g/2TIAKs1t9OHx8R5m+4ChgZ7TkebryP2/nSB67Je906KcPh N/kgEwmM8ld7sIrmG4MQO5c= X-Google-Smtp-Source: AOwi7QDbaT5Yz9DlnIoi1iUX9hZNYj2s0LEVwiRAkTMj7dlRhfznFMUTKcomhQNAxYT2uX0INVMYtg== X-Received: by 10.28.148.67 with SMTP id w64mr14921673wmd.132.1507134652797; Wed, 04 Oct 2017 09:30:52 -0700 (PDT) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-ad89-e054-05c6-3eca.holly.idiocy.org. [2001:8b0:3f8:8129:ad89:e054:5c6:3eca]) by smtp.gmail.com with ESMTPSA id f188sm9067795wme.21.2017.10.04.09.30.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Oct 2017 09:30:51 -0700 (PDT) Date: Wed, 4 Oct 2017 17:30:48 +0100 From: Alan Third To: rswgnu@gmail.com Subject: Re: bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window Message-ID: <20171004163048.GA52414@breton.holly.idiocy.org> References: <83wp4e3nvx.fsf@gnu.org> <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <20171003224017.GA51637@breton.holly.idiocy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.0 (2017-09-02) X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 28620 Cc: 28620@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) On Tue, Oct 03, 2017 at 08:15:53PM -0400, Robert Weiner wrote: > On Tue, Oct 3, 2017 at 6:40 PM, Alan Third wrote: > > As far as I can tell ns_mouse_position returns the frame stored in > > dpyinfo->last_mouse_frame, which is set by EmacsView::mouseDown, however: > > > > If the user clicks a view that isn’t in the key window, by default > > the window is brought forward and made key, but the mouse event is > > not dispatched. > > > > ​What does "the mouse event is not dispatched mean"? Does it mean Emacs > never sees the event? Maybe Emacs sees only that the window has been > selected by the window manager and based on that switches to the selected > window of the frame? Precisely that. > ​The mouse wheel code manages to scroll the proper window that the mouse is > over, even across overlapping frames where the window the mouse is over is > in a frame that is partially behind another frame. And this happens > without without any click events. This could be utilized in the click > event code to get this right somehow. The mouse wheel code is also handled in mouseDown, the difference is that macOS always sends the mouse wheel event to the emacs frame under the mouse pointer, whereas the mouse click event is not sent when the frame is not already key (i.e. selected). AFAICT Emacs does the right thing here, exactly the same thing as every other macOS app. > It looks like the EV_TRAILER macro call at the end of the nsterm.c > mouseDown function (which is also called by mouseUp) sets the frame used > for mouse button down, up and scroll wheel events from the variable > emacsframe. Somehow the value of emacsframe must be set differently for > mouse up events than it is for mouse wheel events since they end up with > different frames for the same mouse positions. There’s nothing fancy here, emacsframe is an instance variable associated with the EmacsView that macOS sends the mouse event to. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 04 13:27:01 2017 Received: (at 28620) by debbugs.gnu.org; 4 Oct 2017 17:27:01 +0000 Received: from localhost ([127.0.0.1]:49159 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dznRl-0007uP-1x for submit@debbugs.gnu.org; Wed, 04 Oct 2017 13:27:01 -0400 Received: from eggs.gnu.org ([208.118.235.92]:54081) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dznRi-0007uA-FS for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 13:26:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dznRa-0005Wk-0p for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 13:26:53 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,HTML_MESSAGE, RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33008) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dznRZ-0005Wc-Sz for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 13:26:49 -0400 Received: from mail-qt0-f178.google.com ([209.85.216.178]:53721) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1dznRZ-0006LD-Cg for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 13:26:49 -0400 Received: by mail-qt0-f178.google.com with SMTP id 47so20585291qts.10 for <28620@debbugs.gnu.org>; Wed, 04 Oct 2017 10:26:49 -0700 (PDT) X-Gm-Message-State: AMCzsaVnoHrpegU4jC7wo6gEwiQRbxWlF2AmJJVL6ksGgohKNcQpzpz+ MLgT5MyLlaMrc6Yjv3rP6v7an7AlhoWye9XQ0Jw= X-Google-Smtp-Source: AOwi7QCicMr+ISpzwx0y5z4V6BStQUDvr6lhRiWapCstPTKQLNibE2PB53zKKtAzfNa+UE9V60lkoGBDnN1Ll9I0zEQ= X-Received: by 10.200.44.118 with SMTP id e51mr12545752qta.171.1507138008873; Wed, 04 Oct 2017 10:26:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.34.225 with HTTP; Wed, 4 Oct 2017 10:26:18 -0700 (PDT) In-Reply-To: <20171004163048.GA52414@breton.holly.idiocy.org> References: <83wp4e3nvx.fsf@gnu.org> <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <20171003224017.GA51637@breton.holly.idiocy.org> <20171004163048.GA52414@breton.holly.idiocy.org> From: Robert Weiner Date: Wed, 4 Oct 2017 13:26:18 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window To: Alan Third Content-Type: multipart/alternative; boundary="001a11405bcea581eb055abbe968" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 28620 Cc: 28620@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rswgnu@gmail.com Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) --001a11405bcea581eb055abbe968 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 4, 2017 at 12:30 PM, Alan Third wrote: > On Tue, Oct 03, 2017 at 08:15:53PM -0400, Robert Weiner wrote: > > On Tue, Oct 3, 2017 at 6:40 PM, Alan Third wrote: > > > As far as I can tell ns_mouse_position returns the frame stored in > > > dpyinfo->last_mouse_frame, which is set by EmacsView::mouseDown, > however: > > > > > > If the user clicks a view that isn=E2=80=99t in the key window, b= y default > > > the window is brought forward and made key, but the mouse event i= s > > > not dispatched. > > > > > > > =E2=80=8BWhat does "the mouse event is not dispatched mean"? Does it m= ean Emacs > > never sees the event? Maybe Emacs sees only that the window has been > > selected by the window manager and based on that switches to the select= ed > > window of the frame? > > Precisely that. > =E2=80=8BSo how is it that Emacs processes a drag event when the mouse butt= on is released in the new frame if it never sees the mouseUp (drag release) event?=E2=80=8B If I drag across frames, on mouseUp, the key binding assoc= iated with mouseUp (mouse-1 as opposed to down-mouse-1 is run). =E2=80=8B=E2=80=8B > > > =E2=80=8BThe mouse wheel code manages to scroll the proper window that = the mouse > is > > over, even across overlapping frames where the window the mouse is over > is > > in a frame that is partially behind another frame. And this happens > > without without any click events. This could be utilized in the click > > event code to get this right somehow. > > The mouse wheel code is also handled in mouseDown, the difference is > that macOS always sends the mouse wheel event to the emacs frame under > the mouse pointer, whereas the mouse click event is not sent when the > frame is not already key (i.e. selected). > =E2=80=8BCan you show some sample code that would make macOS send the mouse= drag release event to the frame under the mouse pointer just as the scroll wheel code does. I have looked at this mouseUp code in nsterm.m but cannot get it to do this. I have managed to inject a focus in event to the mouseUp=E2= =80=8B function and make its event frame the key frame (selected frame) but its event frame is the wrong one (it always has the frame of the mouseDown event). =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > AFAICT Emacs does the right thing here, exactly the same thing as > =E2=80=8B=E2=80=8B > every other macOS app. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B =E2=80=8BAs Eli noted, this does not happen under MS Windows. I want to ha= ve behavior that allows for drags across frames. The present code does not, so whether it is consistent with Mac UI guidelines, it is not useful for that purpose. I would like your help in figuring out how to enable such behavior as you seem to understand the macOS event flow well. =E2=80=8B=E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > It looks like the EV_TRAILER macro call at the end of the nsterm.c > =E2=80=8B=E2=80=8B > > mouseDown function (which is also called by mouseUp) sets the frame use= d > =E2=80=8B=E2=80=8B > > for mouse button down, up and scroll wheel events from the variable > =E2=80=8B=E2=80=8B > > emacsframe. Somehow the value of emacsframe must be set differently fo= r > =E2=80=8B=E2=80=8B > > mouse up events than it is for mouse wheel events since they end up wit= h > =E2=80=8B=E2=80=8B > > different frames for the same mouse positions. > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > There=E2=80=99s nothing fancy here, emacsframe is an instance variable > =E2=80=8B=E2=80=8B > associated with the EmacsView that macOS sends the mouse event to. =E2=80=8BSo show me how and where I could set that variable to the frame of= the mouse position at the point of mouseUp=E2=80=8B and I will test it and let = people know if it works. Thanks, Bob --001a11405bcea581eb055abbe968 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 4, 20= 17 at 12:30 PM, Alan Third <al= an@idiocy.org> w= rote:
On Tue, Oct 03, 2017 at 08= :15:53PM -0400, Robert Weiner wrote:
> On Tue, Oct 3, 2017 at 6:40 PM, Alan Third <alan@idiocy.org> wrote:
> > As far as I can tell ns_mouse_position re= turns the frame stored in
> > dpyinfo->last_mouse_frame, which is set by EmacsView::mouseDow= n, however:
> >
> >=C2=A0 =C2=A0 =C2=A0If the user clicks a view that isn=E2=80=99t i= n the key window, by default
> >=C2=A0 =C2=A0 =C2=A0the window is brought forward and made key, bu= t the mouse event is
> >=C2=A0 =C2=A0 =C2=A0not dispatched.
> >
>
> =E2=80=8BWhat does "the mouse event is not dispatched mean"?= =C2=A0 Does it mean Emacs
> never sees the event?=C2=A0 Maybe Emacs sees only that the window has = been
> selected by the window manager and based on that switches to the selec= ted
> window of the frame?

Precisely that.

=E2=80=8BSo how is it tha= t Emacs processes a drag event when the mouse button is released in the new= frame if it never sees the mouseUp (drag release) event?=E2=80=8B=C2=A0 If= I drag across frames, on mouseUp, the key binding associated with mouseUp = (mouse-1 as opposed to down-mouse-1 is run).

=E2=80=8B=E2=80=8B

> =E2=80=8BThe mouse wheel code manages to scroll the proper window that= the mouse is
> over, even across overlapping frames where the window the mouse is ove= r is
> in a frame that is partially behind another frame.=C2=A0 And this happ= ens
> without without any click events.=C2=A0 This could be utilized in the = click
> event code to get this right somehow.

The mouse wheel code is also handled in mouseDown, the difference is=
that macOS always sends the mouse wheel event to the emacs frame under
the mouse pointer, whereas the mouse click event is not sent when the
frame is not already key (i.e. selected).

=E2=80= =8BCan you show some sample code that would make macOS send the mouse drag = release event to the frame under the mouse pointer just as the scroll wheel= code does.=C2=A0 I have looked at this mouseUp code in nsterm.m but cannot= get it to do this.=C2=A0 I have managed to inject a focus in event to the = mouseUp=E2=80=8B function and make its event frame the key frame (selected = frame) but its event frame is the wrong one (it always has the frame of the= mouseDown event).

=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
AFAICT Emacs does the right thing here, = exactly the same thing as
=E2=80=8B=E2=80=8B
every other macOS app.
=E2=80= =8B=E2=80=8B

=E2=80=8B=E2=80=8B
=E2=80=8BAs Eli no= ted, this does not happen under MS Windows.=C2=A0 I want to have behavior t= hat allows for drags across frames.=C2=A0 The present code does not, so whe= ther it is consistent with Mac UI guidelines, it is not useful for that pur= pose.=C2=A0 I would like your help in figuring out how to enable such behav= ior as you seem to understand the macOS event flow well.
=E2=80=8B=E2=80= =8B=E2=80=8B
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
> It looks like the EV_TRAILER macro = call at the end of the nsterm.c
=E2=80=8B=E2=80=8B
> mouseDown function (which is also c= alled by mouseUp) sets the frame used
=E2=80=8B=E2=80=8B
> for mouse button down, up and scrol= l wheel events from the variable
=E2=80=8B=E2=80=8B
> emacsframe.=C2=A0 Somehow the value= of emacsframe must be set differently for
=E2=80=8B=E2=80=8B
> mouse up events than it is for mous= e wheel events since they end up with
=E2=80=8B=E2=80=8B
> different frames for the same mouse= positions.
=E2=80=8B=E2=80=8B=C2=A0
=E2=80=8B=E2=80=8B
There=E2=80=99s nothing fancy her= e, emacsframe is an instance variable
=E2=80=8B=E2=80=8B
associated with the EmacsView that macOS= sends the mouse event to.

=E2=80=8BSo show me how a= nd where I could set that variable to the frame of the mouse position at th= e point of mouseUp=E2=80=8B and I will test it and let people know if it wo= rks.

Thanks,

Bob


--001a11405bcea581eb055abbe968-- From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 04 14:59:12 2017 Received: (at 28620) by debbugs.gnu.org; 4 Oct 2017 18:59:12 +0000 Received: from localhost ([127.0.0.1]:49205 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzosx-0003YY-OZ for submit@debbugs.gnu.org; Wed, 04 Oct 2017 14:59:12 -0400 Received: from mail-wm0-f53.google.com ([74.125.82.53]:57089) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzosv-0003YL-IM for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 14:59:10 -0400 Received: by mail-wm0-f53.google.com with SMTP id l68so11216829wmd.5 for <28620@debbugs.gnu.org>; Wed, 04 Oct 2017 11:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=BDM5OzNuT5AKydOWrVaGBDzgpunHeB65zmc7uSIYe74=; b=JbCyFW53s+JmMVMAuWuOeM80QLpBa5J48ZIWC/3G7WdztAHcXPjn7/JD9wxta1Olsx AAOF5AOaFkM30lQzhuw4853kfvGVoYIGrqDsnhqU/3qOlpE9K5zlNptoP2AtjixXg4S/ rKCUfEae0j/Q6j7VuW+1Xf2X/3cDqMPb0FcBW5W+e/eK6YTvvehjmFbOcY2G/jtSD2y7 qw4chOcOP5LnxfkICLEsftmnsiRnQV7XelXpVODWA9wpRPDAWLAvq6EJUyeVvLZcVcqf szm9YFlmbhsZMwMeRK3QX3SmT7aZHGiOWKUVvLauDWz+wOFqzizqFc3LFZcaK9cdxcfd 1nog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=BDM5OzNuT5AKydOWrVaGBDzgpunHeB65zmc7uSIYe74=; b=sWhmB4NmtBidyjY7oupnV4Ekmv94TctwPMNWWUF6Tx3ZOn1BAPS96eeziZizIkwcVS 38e+sp/bySfyJs6Azc30TT38VY9nx0NS8ZQn1nwR0YKcOBL0JJ0WSNIkbCHJMVHdrA2L +HM35Qwg76ATgdcpTKVlgcFUoKP/YaOr/22/2Bvs6Dj69RxDnUjPmfB182/wuHWlsxZu WTRQlCz0J+f67rBNMj65sLR+jJM0uRZ3gucJZpXysgXBmwVyKxYxxrlbVWFowB/WVu99 EzIxgLO+mq9ze/Qf/rheQgfdlw61cYSILi/6dxdCvK9smR5JOefXR3pxzRYn5HbgGW9Q rpoA== X-Gm-Message-State: AHPjjUjAkDLoVraY6JvihsaSQNg5FIyZrJG7ViAe+P1SjuAb/nr9K/UD uzDl7VqXd/q5FeuG357DLXg= X-Google-Smtp-Source: AOwi7QBIeDl7NnP7zlsYueGvIIzb2+cEhZ3DhxlSuo4U3XrXscTjJU/QZ4b/zTHzlgB1VxqSmN4dsg== X-Received: by 10.28.107.17 with SMTP id g17mr18354981wmc.58.1507143543396; Wed, 04 Oct 2017 11:59:03 -0700 (PDT) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-ad89-e054-05c6-3eca.holly.idiocy.org. [2001:8b0:3f8:8129:ad89:e054:5c6:3eca]) by smtp.gmail.com with ESMTPSA id b11sm151549wrd.91.2017.10.04.11.59.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Oct 2017 11:59:02 -0700 (PDT) Date: Wed, 4 Oct 2017 19:59:00 +0100 From: Alan Third To: rswgnu@gmail.com Subject: Re: bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window Message-ID: <20171004185900.GA52514@breton.holly.idiocy.org> References: <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <20171003224017.GA51637@breton.holly.idiocy.org> <20171004163048.GA52414@breton.holly.idiocy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.0 (2017-09-02) X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 28620 Cc: 28620@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) On Wed, Oct 04, 2017 at 01:26:18PM -0400, Robert Weiner wrote: > On Wed, Oct 4, 2017 at 12:30 PM, Alan Third wrote: > > > On Tue, Oct 03, 2017 at 08:15:53PM -0400, Robert Weiner wrote: > > > On Tue, Oct 3, 2017 at 6:40 PM, Alan Third wrote: > > > > As far as I can tell ns_mouse_position returns the frame stored in > > > > dpyinfo->last_mouse_frame, which is set by EmacsView::mouseDown, > > however: > > > > > > > > If the user clicks a view that isn’t in the key window, by default > > > > the window is brought forward and made key, but the mouse event is > > > > not dispatched. > > > > > > > > > > ​What does "the mouse event is not dispatched mean"? Does it mean Emacs > > > never sees the event? Maybe Emacs sees only that the window has been > > > selected by the window manager and based on that switches to the selected > > > window of the frame? > > > > Precisely that. > > > > ​So how is it that Emacs processes a drag event when the mouse button is > released in the new frame if it never sees the mouseUp (drag release) > event?​ If I drag across frames, on mouseUp, the key binding associated > with mouseUp (mouse-1 as opposed to down-mouse-1 is run). The NSEvent is delivered to the EmacsView belonging to the frame where the drag was initiated. I don’t think there’s anything we can do to change that. > > The mouse wheel code is also handled in mouseDown, the difference is > > that macOS always sends the mouse wheel event to the emacs frame under > > the mouse pointer, whereas the mouse click event is not sent when the > > frame is not already key (i.e. selected). > > > > ​Can you show some sample code that would make macOS send the mouse drag > release event to the frame under the mouse pointer just as the scroll wheel > code does. I have looked at this mouseUp code in nsterm.m but cannot get > it to do this. I have managed to inject a focus in event to the mouseUp​ > function and make its event frame the key frame (selected frame) but its > event frame is the wrong one (it always has the frame of the mouseDown > event). I don’t believe it’s possible. As I described before we’d have to do something like: [...] get a list of NSWindows, iterate over them to find out which one the mouse pointer is over, convert that NSWindow back to an Emacs frame, and [return it]. > > AFAICT Emacs does the right thing here, exactly the same thing as > > every other macOS app. > > > ​As Eli noted, this does not happen under MS Windows. I want to have > behavior that allows for drags across frames. The present code does not, > so whether it is consistent with Mac UI guidelines, it is not useful for > that purpose. I would like your help in figuring out how to enable such > behavior as you seem to understand the macOS event flow well. But which behaviour? I can’t work out exactly what we’re talking about here. Are you trying to get cross‐frame dragging working or are you genuinely concerned that Emacs doesn’t receive a click event when the frame is selected using the mouse? These seem like two different things to me. > > There’s nothing fancy here, emacsframe is an instance variable > > associated with the EmacsView that macOS sends the mouse event to. > > > ​So show me how and where I could set that variable to the frame of the > mouse position at the point of mouseUp​ and I will test it and let people > know if it works. Fns_frame_list_z_order in nsfns.m does some of what’s described above... But... It looks like there’s maybe a neater way to get the current frame under the mouse... Lisp_Object frame = Qnil; NSWindow *w = [NSApp windowWithWindowNumber: [NSWindow windowNumberAtPoint:[NSEvent mouseLocation] belowWindowWithWindowNumber:0]]; if (w != nil) XSETFRAME (frame, ((EmacsView *)[w delegate])->emacsframe); I’ve not tested this, so it may not work at all. Note that [NSEvent mouseLocation] returns an NSPoint indicating where the mouse is *right now*. It would probably be more sensible to use any co‐ordinates provided by the event itself. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 04 15:31:29 2017 Received: (at 28620) by debbugs.gnu.org; 4 Oct 2017 19:31:29 +0000 Received: from localhost ([127.0.0.1]:49213 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzpOC-0004L5-Fh for submit@debbugs.gnu.org; Wed, 04 Oct 2017 15:31:29 -0400 Received: from eggs.gnu.org ([208.118.235.92]:59482) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzpO9-0004Ks-FS for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 15:31:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzpO0-00063K-Qh for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 15:31:20 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,HTML_MESSAGE, RP_MATCHES_RCVD,URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35590) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzpO0-000639-N9 for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 15:31:16 -0400 Received: from mail-qk0-f170.google.com ([209.85.220.170]:54592) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1dzpO0-00087K-Bc for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 15:31:16 -0400 Received: by mail-qk0-f170.google.com with SMTP id n5so10352680qke.11 for <28620@debbugs.gnu.org>; Wed, 04 Oct 2017 12:31:16 -0700 (PDT) X-Gm-Message-State: AMCzsaXv24iQ7unVwRdFPdnRWQ3catkCcLsaW01lhEt6Er60ioHLD5Hz uCuWfa/9GiOQ7sNGXaWmmY9sFOjnfVxX0+jE/yo= X-Google-Smtp-Source: AOwi7QADgFz1KE0FvfuEbnD5dWPhA2xFSddfzqI96UiLFb+XB18X3V8bJuu0xynK2b5DlA8B+YpSqJN4jtDP4617ALI= X-Received: by 10.55.19.228 with SMTP id 97mr25344470qkt.271.1507145475759; Wed, 04 Oct 2017 12:31:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.34.225 with HTTP; Wed, 4 Oct 2017 12:30:45 -0700 (PDT) In-Reply-To: <20171004185900.GA52514@breton.holly.idiocy.org> References: <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <20171003224017.GA51637@breton.holly.idiocy.org> <20171004163048.GA52414@breton.holly.idiocy.org> <20171004185900.GA52514@breton.holly.idiocy.org> From: Robert Weiner Date: Wed, 4 Oct 2017 15:30:45 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window To: Alan Third Content-Type: multipart/alternative; boundary="001a113fe9f0b52294055abda692" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 28620 Cc: 28620@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rswgnu@gmail.com Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) --001a113fe9f0b52294055abda692 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alan: Thanks for your thoughts on this. On Wed, Oct 4, 2017 at 2:59 PM, Alan Third wrote: > On Wed, Oct 04, 2017 at 01:26:18PM -0400, Robert Weiner wrote: > > > =E2=80=8BSo how is it that Emacs processes a drag event when the mouse = button is > > released in the new frame if it never sees the mouseUp (drag release) > > event?=E2=80=8B If I drag across frames, on mouseUp, the key binding a= ssociated > > with mouseUp (mouse-1 as opposed to down-mouse-1 is run). > > The NSEvent is delivered to the EmacsView belonging to the frame where > the drag was initiated. I don=E2=80=99t think there=E2=80=99s anything we= can do to > change that. > =E2=80=8BSo you are saying that only one NSEvent is delivered to Emacs for = both the press and release of a drag that crosses frames? And that Emacs internally internally recognizes both the press and release of the mouse button and fires their respective key bindings but they both share the location from that one NSEvent? If so, why can't the nsterm.m mouseUp (release) handler synthesize an NSEvent based on the current mouse position that is run prior to invoking the keybinding for mouseUp? =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > > The mouse wheel code is also handled in > =E2=80=8B=E2=80=8B > mouseDown, the difference is > =E2=80=8B=E2=80=8B > > > that macOS always sends the mouse whe > =E2=80=8B=E2=80=8B > el event to the emacs frame under > =E2=80=8B=E2=80=8B > > > the mouse pointer, whereas the mouse cli > =E2=80=8B=E2=80=8B > ck event is not sent when the > =E2=80=8B=E2=80=8B > > > frame is not already key (i.e. selected). > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B =E2=80=8BOk, I understand that now.=E2=80=8B =E2=80=8B=E2=80=8B=E2=80=8B > =E2=80=8B > > =E2=80=8BCan you show some sample code that would make macOS send the m= ouse drag > =E2=80=8B=E2=80=8B > > release event to the frame under the mouse pointer just as the scroll > wheel > =E2=80=8B=E2=80=8B > > > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > c > =E2=80=8B=E2=80=8B > o > =E2=80=8B=E2=80=8B > d > =E2=80=8B=E2=80=8B > e > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > d > =E2=80=8B=E2=80=8B > o > =E2=80=8B=E2=80=8B > e > =E2=80=8B=E2=80=8B > s > =E2=80=8B=E2=80=8B > . > =E2=80=8B > > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > I don=E2=80=99t believe it=E2=80=99s possible. As I described before we= =E2=80=99d have to do > =E2=80=8B=E2=80=8B > something like: > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > [...] get a list of NSWindows, iterate over them to find out which > =E2=80=8B=E2=80=8B > one the mouse pointer is over, convert that NSWindow back to an Emacs > =E2=80=8B=E2=80=8B > frame, and [return it]. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > > AFAICT Emacs does the right thing here, exactly the same thing as > =E2=80=8B=E2=80=8B > > > every other macOS app. > =E2=80=8B=E2=80=8B > > > > =E2=80=8B=E2=80=8B > > =E2=80=8BAs Eli noted, this does not happen under MS Windows. =E2=80=8BI just tested under MS Windows 7 with Emacs 25 and saw the same be= havior as on the Mac (mouse-1 drag between frames yields a release event with the depress frame rather than the release frame). I'll have to talk to Eli about this. =E2=80=8B > =E2=80=8B=E2=80=8B > I want to have > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > behavior that allows for drags across frames. The present code does no= t, > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > so whether it is consistent with Mac UI guidelines, it is not useful fo= r > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > that purpose. I would like your help in figuring out how to enable su > =E2=80=8B=E2=80=8B > ch > =E2=80=8B=E2=80=8B > > behavior as you seem to understand the macOS event flow well. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > But which behaviour? I can=E2=80=99t work out exactly what we=E2=80=99re = talking ab > =E2=80=8B=E2=80=8B > out > =E2=80=8B=E2=80=8B > here. Are you trying to get cross=E2=80=90frame dragging working =E2=80=8BYes.=E2=80=8B =E2=80=8B=E2=80=8B > or > =E2=80=8B=E2=80=8B > are you > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > genuinely concerned that Emacs doesn=E2=80=99t receive a click event when= the > =E2=80=8B=E2=80=8B > frame is selected using the mouse? These seem like two different > =E2=80=8B=E2=80=8B > things to me. > =E2=80=8BI want to work around that if possible. The fact that Emacs can d= ispatch on the mouseUp=E2=80=8B event tells me that we just need to determine the p= roper window of mouse position at that point and use that instead of the frame the Mac window system provides. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > > There=E2=80=99s nothing fancy here, emacsframe is an instance variabl= e > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > > associated with the EmacsView that macOS sends the mouse > =E2=80=8B=E2=80=8B > event to. > =E2=80=8B=E2=80=8B > > > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > > =E2=80=8B=E2=80=8B > =E2=80=8BSo show me how and where I could set that variable to the frame = of the > =E2=80=8B=E2=80=8B > > > =E2=80=8B=E2=80=8B > mouse position at the point of mouseUp=E2=80=8B and I will test it and le= t people > =E2=80=8B=E2=80=8B > > > =E2=80=8B=E2=80=8B > know if it works. > =E2=80=8B=E2=80=8B > > F > =E2=80=8B=E2=80=8B > ns_frame_list_z_order in nsfns.m does some of what=E2=80=99s described > a > =E2=80=8B=E2=80=8B > bove... But... > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > It looks like there=E2=80=99s maybe a neater way to get the current frame > =E2=80=8B=E2=80=8B > under the mouse... > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > Lisp_Object frame =3D Qnil; > =E2=80=8B=E2=80=8B > NSWindow *w =3D [NSApp windowWithWindowNumber: > =E2=80=8B=E2=80=8B > [NSWindow windowNumberAtPoint:[NSEvent > mouseLocation] > =E2=80=8B=E2=80=8B > belowWindowWithWindowNumber:0]]; > =E2=80=8B=E2=80=8B > if (w !=3D nil) > =E2=80=8B=E2=80=8B > XSETFRAME (frame, ((EmacsView *)[w delegate])->emacsframe); > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > I=E2=80=99ve not tested this, so it may not work at all. Note that [NSEve= nt > =E2=80=8B=E2=80=8B > mouseLocation] returns an NSPoint indicating where the mouse is *right > =E2=80=8B=E2=80=8B > now*. It would probably be more sensible to use any co=E2=80=90ordinates > =E2=80=8B=E2=80=8B > provided by the event itself. > If the coordinates represent the location of the mouseUp event rather than mouseDown (of which I'm not sure), then why couldn't the frame differ as well when we have the right functionality together? Let me see if I can test with mouseLocation first. I would suggest that the (mouse-position) function should always return the uppermost Z-ordered frame at point, even though it fails to do that now. Bob --001a113fe9f0b52294055abda692 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alan:

Thanks for your thoughts on this.

On Wed, Oct 4, 2017 at 2= :59 PM, Alan Third <alan@idiocy.org> wrote:
On Wed, Oct 04, 2017 at 01:26:18PM -0400, = Robert Weiner wrote:

> =E2=80=8BSo how is it that Emacs processes a drag event when the mouse= button is
> released in the new frame if it never sees the mouseUp (drag release)<= br> > event?=E2=80=8B=C2=A0 If I drag across frames, on mouseUp, the key bin= ding associated
> with mouseUp (mouse-1 as opposed to down-mouse-1 is run).

The NSEvent is delivered to the EmacsView belonging to the frame whe= re
the drag was initiated. I don=E2=80=99t think there=E2=80=99s anything we c= an do to
change that.

=E2=80=8BSo you are saying that onl= y one NSEvent is delivered to Emacs for both the press and release of a dra= g that crosses frames?
And that Emacs internally internally recognizes bot= h the press and release of the mouse button and fires their respective key = bindings but they both share the location from that one NSEvent?

If = so, why can't the nsterm.m mouseUp (release) handler synthesize an NSEv= ent based on the current mouse position that is run prior to invoking the k= eybinding for mouseUp?

=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
> > The mouse wheel code is also h= andled in
=E2=80=8B=E2=80=8B
mouseDown, the difference is
=E2=80=8B=E2=80=8B
> > that macOS always sends the mo= use whe
=E2=80=8B=E2=80=8B
el event to the emacs frame under=
=E2=80=8B=E2=80=8B
> > the mouse pointer, whereas the= mouse cli
=E2=80=8B=E2=80=8B
ck event is not sent when the<= br>
=E2=80=8B=E2=80=8B
> > frame is not already key (i.e.= selected).
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
=E2=80=8BOk, I un= derstand that now.=E2=80=8B
=E2=80=8B=E2=80=8B=E2=80=8B
=E2= =80=8B
> =E2=80=8BCan you show some sample code that would make mac= OS send the mouse drag
=E2=80=8B=E2=80=8B
> release event to the frame under th= e mouse pointer just as the scroll wheel
=E2=80=8B=E2=80=8B
>
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
c
=E2=80=8B=E2=80=8B
o<= div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displa= y:inline">=E2=80=8B=E2=80=8B
d
=E2=80=8B=E2=80=8B
e=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
d
=E2=80=8B=E2=80=8B
o
=E2=80=8B=E2=80=8B
e
=E2=80=8B=E2=80=8B
s
=E2=80=8B=E2=80=8B
.
= =E2=80=8B

=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
I don=E2=80=99t believe it=E2=80= =99s possible. As I described before we=E2=80=99d have to do
=E2=80=8B=E2=80=8B
something like:
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 [...] get a list of NSWind= ows, iterate over them to find out which
=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 one the m= ouse pointer is over, convert that NSWindow back to an Emacs
=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 frame, and [return = it].
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
> > AFAICT Emacs does the right th= ing here, exactly the same thing as
=E2=80=8B=E2=80=8B
> > every other macOS app.
=E2=80=8B=E2=80=8B
> >
=E2=80=8B=E2=80=8B
> =E2=80=8BAs Eli noted, this does no= t happen under MS Windows.

=E2=80=8BI just te= sted under MS Windows 7 with Emacs 25 and saw the same behavior as on the M= ac (mouse-1 drag between frames yields a release event with the depress fra= me rather than the release frame).=C2=A0 I'll have to talk to Eli about= this.
=E2=80=8B
=E2=80=8B=E2=80=8B
=C2=A0 I want to have=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2= =80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80= =8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B= =E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2= =80=8B

=E2=80=8B=E2=80=8B
> behavior that allows for drags acro= ss frames.=C2=A0 The present code does not,
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
> so whether it is consistent with Ma= c UI guidelines, it is not useful for
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
> that purpose.=C2=A0 I would like yo= ur help in figuring out how to enable su
=E2=80=8B=E2=80=8Bch
=E2=80=8B=E2=80=8B
> behavior as you seem to understand = the macOS event flow well.
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
But which behaviour? I can=E2=80= =99t work out exactly what we=E2=80=99re talking ab
=E2=80=8B=E2= =80=8B
out
=E2=80=8B=E2=80=8B
here. Are you trying to get cross=E2=80= =90frame dragging working

=E2=80=8BYes.=E2=80=8B
=E2= =80=8B=E2=80=8B
or
=E2=80=8B=E2=80=8B
are you
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2= =80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80= =8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B= =E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2= =80=8B
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
genuinely concerned that Emacs doesn=E2= =80=99t receive a click event when the
=E2=80=8B=E2=80=8B
frame is selected using the mouse? These= seem like two different
=E2=80=8B=E2=80=8B
things to me.

<= /div>
=E2=80=8BI want to work around that if possible.=C2=A0 The fact that Emacs= can dispatch on the mouseUp=E2=80=8B event tells me that we just need to d= etermine the proper window of mouse position at that point and use that ins= tead of the frame the Mac window system provides.
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
> > There=E2=80=99s nothing fancy = here, emacsframe is an instance variable
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
> > associated with the EmacsView = that macOS sends the mouse
=E2=80=8B=E2=80=8B
event to.
=E2=80=8B=E2=80=8B
>
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
>
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
>
=E2=80=8B=E2=80=8B =E2=80=8BSo show me how and where I could set that variable to the frame = of the
=E2=80=8B=E2=80=8B
>
=E2=80=8B=E2=80=8B mouse position at the point of mouseUp=E2=80=8B and I will test it and le= t people
=E2=80=8B=E2=80=8B
>
=E2=80=8B=E2=80=8B know if it works.
=E2=80=8B=E2=80=8B

F
=E2=80=8B=E2=80=8B
ns_frame_list_z_order in nsfns.m= does some of what=E2=80=99s described
a
=E2=80=8B=E2=80=8B
bove... But...
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
It looks like there=E2=80=99s maybe a ne= ater way to get the current frame
=E2=80=8B=E2=80=8B
under the mouse...
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 Lisp_Object frame =3D Qnil= ;
=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 NSWindow *w =3D [NSApp win= dowWithWindowNumber:
=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[NSWindow windowNumberA= tPoint:[NSEvent mouseLocation]
=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0belowWindowWithW= indowNumber:0]];
=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 if (w !=3D nil)
=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 =C2=A0 XSETFRAME (frame, (= (EmacsView *)[w delegate])->emacsframe);
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
I=E2=80=99ve not tested this, so it may = not work at all. Note that [NSEvent
=E2=80=8B=E2=80=8B
mouseLocation] returns an NSPoint indica= ting where the mouse is *right
=E2=80=8B=E2=80=8B
now*. It would probably be more sensible= to use any co=E2=80=90ordinates
=E2=80=8B=E2=80=8B
provided by the event itself.

If the coordinates represent the location of the mouseUp e= vent rather than mouseDown (of which I'm not sure), then why couldn'= ;t the frame differ as well when we have the right functionality together?= =C2=A0 Let me see if I can test with mouseLocation first.

I would = suggest that the (mouse-position) function should always return the uppermo= st Z-ordered frame at point, even though it fails to do that now.

Bo= b
--001a113fe9f0b52294055abda692-- From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 04 16:08:38 2017 Received: (at 28620) by debbugs.gnu.org; 4 Oct 2017 20:08:38 +0000 Received: from localhost ([127.0.0.1]:49274 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzpyA-0005MI-B2 for submit@debbugs.gnu.org; Wed, 04 Oct 2017 16:08:38 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41340) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzpy8-0005M4-B7 for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 16:08:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzpy0-0003VV-2J for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 16:08:31 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE, RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36298) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzpxz-0003VN-Uo for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 16:08:27 -0400 Received: from mail-qt0-f177.google.com ([209.85.216.177]:53991) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1dzpxz-0007wV-LT for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 16:08:27 -0400 Received: by mail-qt0-f177.google.com with SMTP id 47so21503369qts.10 for <28620@debbugs.gnu.org>; Wed, 04 Oct 2017 13:08:27 -0700 (PDT) X-Gm-Message-State: AMCzsaUd4VrdhB2NjyQ58i+9YXiwqsQybtFElJ3oQnvchRfOJy/akI+B GNMDLoIfHteIG6F8iUTXexnYRoP1+FT6f89R2hs= X-Google-Smtp-Source: AOwi7QBzueAXurmG2KGvfM+05u0ftX/jxndcMU6+4urbZLiSyYSgunoMUO3+qjEG5pSgeTd+Zg7yWHEY+BYGFDmZcXU= X-Received: by 10.200.57.29 with SMTP id s29mr31435484qtb.309.1507147707257; Wed, 04 Oct 2017 13:08:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.34.225 with HTTP; Wed, 4 Oct 2017 13:07:56 -0700 (PDT) In-Reply-To: <20171004185900.GA52514@breton.holly.idiocy.org> References: <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <20171003224017.GA51637@breton.holly.idiocy.org> <20171004163048.GA52414@breton.holly.idiocy.org> <20171004185900.GA52514@breton.holly.idiocy.org> From: Robert Weiner Date: Wed, 4 Oct 2017 16:07:56 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window To: Alan Third Content-Type: multipart/alternative; boundary="001a11418c4eb72a06055abe2b17" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 28620 Cc: 28620@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rswgnu@gmail.com Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.5 (----) --001a11418c4eb72a06055abe2b17 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 4, 2017 at 2:59 PM, Alan Third wrote: > > It looks like there=E2=80=99s maybe a neater way to get the current frame > under the mouse... > > Lisp_Object frame =3D Qnil; > NSWindow *w =3D [NSApp windowWithWindowNumber: > [NSWindow windowNumberAtPoint:[NSEvent > mouseLocation] > belowWindowWithWindowNumber:0]]; > if (w !=3D nil) > XSETFRAME (frame, ((EmacsView *)[w delegate])->emacsframe); > > The =E2=80=8BmouseDown=E2=80=8B function (called by the various mouseUp fun= ctions) uses `emacsframe' to set the appropriate frame. How does the above modify emacsframe? Doesn't XSETFRAME just set the value of the local `frame'? Bob --001a11418c4eb72a06055abe2b17 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 4, 20= 17 at 2:59 PM, Alan Third <ala= n@idiocy.org> wr= ote:
=

It looks like there=E2=80=99s maybe a neater way to get the current frame under the mouse...

=C2=A0 =C2=A0 Lisp_Object frame =3D Qnil;
=C2=A0 =C2=A0 NSWindow *w =3D [NSApp windowWithWindowNumber:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0[NSWindow windowNumberAtPoint:[NSEvent mouseLocation]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0belowWindowWithWindowNumber:0]];
=C2=A0 =C2=A0 if (w !=3D nil)
=C2=A0 =C2=A0 =C2=A0 XSETFRAME (frame, ((EmacsView *)[w delegate])->emac= sframe);


The =E2=80=8BmouseDown=E2=80=8B function (calle= d by the various mouseUp functions) uses `emacsframe' to set the approp= riate frame.
How does the above modify emacsframe?=C2=A0 Doesn't XSETF= RAME just set the value of the local `frame'?

Bob


--001a11418c4eb72a06055abe2b17-- From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 04 16:12:26 2017 Received: (at 28620) by debbugs.gnu.org; 4 Oct 2017 20:12:26 +0000 Received: from localhost ([127.0.0.1]:49278 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzq1p-0005SW-UR for submit@debbugs.gnu.org; Wed, 04 Oct 2017 16:12:26 -0400 Received: from eggs.gnu.org ([208.118.235.92]:42282) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzq1n-0005SH-Us for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 16:12:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzq1f-00079Y-NW for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 16:12:18 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE, RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36470) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzq1f-00079B-KM for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 16:12:15 -0400 Received: from mail-qt0-f170.google.com ([209.85.216.170]:45621) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1dzq1f-0008Jh-6E for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 16:12:15 -0400 Received: by mail-qt0-f170.google.com with SMTP id k1so10564423qti.2 for <28620@debbugs.gnu.org>; Wed, 04 Oct 2017 13:12:15 -0700 (PDT) X-Gm-Message-State: AMCzsaUzBwX3cjAs6GxQFLkMjaFJlwXhL8UV9J/opVdKmAcRmOep5tv4 q9Rrt3u4AwRRufFgKQy0pbd6iT6tZUmZwYE37pM= X-Google-Smtp-Source: AOwi7QBnaDobC9TdHzJQoIuwAi1kIMhiJDoBHOWRiK+jdZAVB7v4UZwuJK9LzNBexVQmGSnCXx1vMqwU4Vvzxx7tzyA= X-Received: by 10.200.26.65 with SMTP id q1mr28751245qtk.186.1507147934772; Wed, 04 Oct 2017 13:12:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.34.225 with HTTP; Wed, 4 Oct 2017 13:11:44 -0700 (PDT) In-Reply-To: References: <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <20171003224017.GA51637@breton.holly.idiocy.org> <20171004163048.GA52414@breton.holly.idiocy.org> <20171004185900.GA52514@breton.holly.idiocy.org> From: Robert Weiner Date: Wed, 4 Oct 2017 16:11:44 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window To: Alan Third Content-Type: multipart/alternative; boundary="f403045d6da046b1a2055abe3998" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 28620 Cc: 28620@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rswgnu@gmail.com Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.5 (----) --f403045d6da046b1a2055abe3998 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 4, 2017 at 3:30 PM, Robert Weiner wrote: > Hi Alan: > >> >> =E2=80=8B=E2=80=8B >> It looks like there=E2=80=99s maybe a neater way to get the current fram= e >> =E2=80=8B=E2=80=8B >> under the mouse... >> =E2=80=8B=E2=80=8B >> >> =E2=80=8B=E2=80=8B >> Lisp_Object frame =3D Qnil; >> =E2=80=8B=E2=80=8B >> NSWindow *w =3D [NSApp windowWithWindowNumber: >> =E2=80=8B=E2=80=8B >> [NSWindow windowNumberAtPoint:[NSEvent >> mouseLocation] >> =E2=80=8B=E2=80=8B >> belowWindowWithWindowNumber:0]]; >> =E2=80=8B=E2=80=8B >> if (w !=3D nil) >> =E2=80=8B=E2=80=8B >> XSETFRAME (frame, ((EmacsView *)[w delegate])->emacsframe); >> > =E2=80=8BAs is, this didn't seem to have any effect. Bob =E2=80=8B --f403045d6da046b1a2055abe3998 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 4, 20= 17 at 3:30 PM, Robert Weiner <rsw@= gnu.org> wrote:<= /span>
Hi Alan:
=
=E2=80=8B=E2= =80=8B
It looks like there=E2=80=99s maybe a neater way to get the cur= rent frame
=E2=80=8B=E2= =80=8B
under the mouse...
=E2=80=8B=E2= =80=8B

=E2=80=8B=E2= =80=8B
=C2=A0 =C2=A0 Lisp_Object frame =3D Qnil;
=E2=80=8B=E2= =80=8B
=C2=A0 =C2=A0 NSWindow *w =3D [NSApp windowWithWindowNumber:
=E2=80=8B=E2= =80=8B
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0[NSWindow windowNumberAtPoint:[NSEvent mouseLoca= tion]
=E2=80=8B=E2= =80=8B
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0belowWindowWithWindowNumber:0]];
=E2=80=8B=E2= =80=8B
=C2=A0 =C2=A0 if (w !=3D nil)
=E2=80=8B=E2= =80=8B
=C2=A0 =C2=A0 =C2=A0 XSETFRAME (frame, ((EmacsView *)[w delegat= e])->emacsframe);
=

=E2=80=8BAs is, this didn't seem to have any effect.

= Bob
=E2=80=8B
--f403045d6da046b1a2055abe3998-- From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 04 18:09:14 2017 Received: (at 28620) by debbugs.gnu.org; 4 Oct 2017 22:09:14 +0000 Received: from localhost ([127.0.0.1]:49436 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzrqs-0008OG-1J for submit@debbugs.gnu.org; Wed, 04 Oct 2017 18:09:14 -0400 Received: from mail-wm0-f53.google.com ([74.125.82.53]:43154) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzrqo-0008Nz-LL for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 18:09:13 -0400 Received: by mail-wm0-f53.google.com with SMTP id m72so15835362wmc.0 for <28620@debbugs.gnu.org>; Wed, 04 Oct 2017 15:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=AhOMM8hRJFDQdk5UfRUrCwSUfLZxj6dCQv0QEoOvt0A=; b=dSQdjWqno6igUPrY2mbPIsF6yUihjKfmJSXohwUZ4Fi1YZwbZrhQBu6P0EPq6tCG+5 LZutIvt+PB6sKTllHFuTlKcIm331IuE3evCWZz6nC87roFWmoCIEAO8Zyshry2AJAscQ 0K/7z2Sn0DlFbGaoKOglvtUC5B5oaNFtr+Cgzja4wMh/KinrZrzTHJuX7oo/tOuqFfhe UY+WPzGvKmYoSv+xHfEFKCjquy10Vnui5LAqCph2xbZ9k+liAzR6mitZmRLND8Vo0SZd S1d59H1y31h0ulDjHK3jyYa1ZphKRZ9Yji66LP/f/rB/IEQvBKSb7jnv53p8IofjupRA fQ5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=AhOMM8hRJFDQdk5UfRUrCwSUfLZxj6dCQv0QEoOvt0A=; b=n8qr5iGcOpaFWbjZwtAfoIz18cBIaSC7TCrOjha2rrr9X9KwB90HZywcOFtLvdkwCM 6bxaf3dCIAnpzjF12PZsPCAv1GXhc41iZtYFVYVAB6gmvH26+grkyaPy9vnt21YdQT+A dqFEyER8BJKnPimWcwlG4Jf8yp8xHCA6HGZlv+Nu+iMg2j4WCj37hQQDeqovOVLcEmA/ QJ0wMdGlymA20XOYYEu9AwGwG06+S5l556WkVvkExiSdahatDPstk2c6gRvmqgaAM9lL 3eaykQc40BpIghEUYqpqdzuY6DPg2FFyIjc8ugVQpc1NF8XKCGWV7gJy4KWN7ds3HVbW nHtA== X-Gm-Message-State: AMCzsaVzWD5gIafZHV4+9dvJV6mtL36KizAHIpChAHS4Pk2sHKu8wM8n xBSukyypP1/ytGSqo40ohEo= X-Google-Smtp-Source: AOwi7QBeqamZndyxfI8F2iDK2HIg+Eyt78SHssaylToLKhP8bYOdnoxkMxVQ+FqySnN1dT/K/rqs8Q== X-Received: by 10.28.208.129 with SMTP id h123mr9611794wmg.25.1507154944915; Wed, 04 Oct 2017 15:09:04 -0700 (PDT) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-ad89-e054-05c6-3eca.holly.idiocy.org. [2001:8b0:3f8:8129:ad89:e054:5c6:3eca]) by smtp.gmail.com with ESMTPSA id 193sm13310108wmh.47.2017.10.04.15.09.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Oct 2017 15:09:03 -0700 (PDT) Date: Wed, 4 Oct 2017 23:09:01 +0100 From: Alan Third To: rswgnu@gmail.com Subject: Re: bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window Message-ID: <20171004220901.GA52814@breton.holly.idiocy.org> References: <8360bw19es.fsf@gnu.org> <20171003224017.GA51637@breton.holly.idiocy.org> <20171004163048.GA52414@breton.holly.idiocy.org> <20171004185900.GA52514@breton.holly.idiocy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.0 (2017-09-02) X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 28620 Cc: 28620@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) On Wed, Oct 04, 2017 at 04:07:56PM -0400, Robert Weiner wrote: > On Wed, Oct 4, 2017 at 2:59 PM, Alan Third wrote: > > > > > It looks like there’s maybe a neater way to get the current frame > > under the mouse... > > > > Lisp_Object frame = Qnil; > > NSWindow *w = [NSApp windowWithWindowNumber: > > [NSWindow windowNumberAtPoint:[NSEvent > > mouseLocation] > > belowWindowWithWindowNumber:0]]; > > if (w != nil) > > XSETFRAME (frame, ((EmacsView *)[w delegate])->emacsframe); > > > > > The ​mouseDown​ function (called by the various mouseUp functions) uses > `emacsframe' to set the appropriate frame. > How does the above modify emacsframe? Doesn't XSETFRAME just set the value > of the local `frame'? Yes. You can’t modify emacsframe because it’s an instance variable. You’ll need to modify whatever is using it to set the frame in the emacs event. So, assuming the code you’re modifying is calling EV_TRAILER, for now, replace the call to EV_TRAILER with it’s contents: XSETFRAME (emacs_event->frame_or_window, emacsframe); EV_TRAILER2 (e); and work from there. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 04 20:39:20 2017 Received: (at 28620) by debbugs.gnu.org; 5 Oct 2017 00:39:20 +0000 Received: from localhost ([127.0.0.1]:49509 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzuC8-0003h1-4w for submit@debbugs.gnu.org; Wed, 04 Oct 2017 20:39:20 -0400 Received: from eggs.gnu.org ([208.118.235.92]:48073) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzuC6-0003gn-UL for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 20:39:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzuBx-0002Yw-Ct for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 20:39:13 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE, RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40127) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzuBx-0002Yo-A6 for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 20:39:09 -0400 Received: from mail-qt0-f177.google.com ([209.85.216.177]:53930) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1dzuBx-0003oE-1J for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 20:39:09 -0400 Received: by mail-qt0-f177.google.com with SMTP id 47so22561400qts.10 for <28620@debbugs.gnu.org>; Wed, 04 Oct 2017 17:39:08 -0700 (PDT) X-Gm-Message-State: AMCzsaVjHMNxnHgaly61RHzi4EX5W4A0+OOkVeSbpNdPRte1kehbEIVc 2TBcYtMVRqTArnurblYwMmhRAJrJyEbgc/rxRVU= X-Google-Smtp-Source: AOwi7QBfw4XfVjN82yckSkORz3XYVZdTrdjBX+7K7mKrmaeF9WpsEP+psAm5+sSGJiPFHYFvgZefadFCbkHKyrYkj14= X-Received: by 10.200.26.65 with SMTP id q1mr29618373qtk.186.1507163948605; Wed, 04 Oct 2017 17:39:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.34.225 with HTTP; Wed, 4 Oct 2017 17:38:38 -0700 (PDT) In-Reply-To: <20171004220901.GA52814@breton.holly.idiocy.org> References: <8360bw19es.fsf@gnu.org> <20171003224017.GA51637@breton.holly.idiocy.org> <20171004163048.GA52414@breton.holly.idiocy.org> <20171004185900.GA52514@breton.holly.idiocy.org> <20171004220901.GA52814@breton.holly.idiocy.org> From: Robert Weiner Date: Wed, 4 Oct 2017 20:38:38 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window To: Alan Third Content-Type: multipart/alternative; boundary="f403045d6da0c6666b055ac1f3c8" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 28620 Cc: 28620@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rswgnu@gmail.com Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.5 (----) --f403045d6da0c6666b055ac1f3c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 4, 2017 at 6:09 PM, Alan Third wrote: > > Yes. You can=E2=80=99t modify emacsframe because it=E2=80=99s an instance= variable. > You=E2=80=99ll need to modify whatever is using it to set the frame in th= e > emacs event. > > So, assuming the code you=E2=80=99re modifying is calling EV_TRAILER, for= now, > replace the call to EV_TRAILER with it=E2=80=99s contents: > > XSETFRAME (emacs_event->frame_or_window, emacsframe); > EV_TRAILER2 (e); > > and work from there. > =E2=80=8BStill doesn't seem to work if that code is used at the end of mous= eDown (called by mouseUp). Could you test any of your ideas? It would probably speed the process up if you have a bit of time. Bob --f403045d6da0c6666b055ac1f3c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 4, 20= 17 at 6:09 PM, Alan Third <ala= n@idiocy.org> wr= ote:
=

Yes. You can=E2=80=99t modify emacsframe because it=E2=80=99s an ins= tance variable.
You=E2=80=99ll need to modify whatever is using it to set the frame in the<= br> emacs event.

So, assuming the code you=E2=80=99re modifying is calling EV_TRAILER, for n= ow,
replace the call to EV_TRAILER with it=E2=80=99s contents:

=C2=A0 =C2=A0 XSETFRAME (emacs_event->frame_or_window, emacsframe);
=C2=A0 =C2=A0 EV_TRAILER2 (e);

and work from there.

=E2=80=8BStill doesn't = seem to work if that code is used at the end of mouseDown (called by mouseU= p).
Could you test any of your ideas?=C2=A0 It would probably speed the pr= ocess up if you have a bit of time.

Bob
--f403045d6da0c6666b055ac1f3c8-- From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 11 14:50:28 2017 Received: (at 28620) by debbugs.gnu.org; 11 Oct 2017 18:50:28 +0000 Received: from localhost ([127.0.0.1]:34457 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2M5M-0004a1-7M for submit@debbugs.gnu.org; Wed, 11 Oct 2017 14:50:28 -0400 Received: from eggs.gnu.org ([208.118.235.92]:58818) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2M5K-0004Zn-Bg for 28620@debbugs.gnu.org; Wed, 11 Oct 2017 14:50:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e2M5B-00005k-Sn for 28620@debbugs.gnu.org; Wed, 11 Oct 2017 14:50:21 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE, RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56514) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2M5B-00005P-Jb for 28620@debbugs.gnu.org; Wed, 11 Oct 2017 14:50:17 -0400 Received: from mail-qt0-f178.google.com ([209.85.216.178]:56301) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1e2M5B-0004XK-3d for 28620@debbugs.gnu.org; Wed, 11 Oct 2017 14:50:17 -0400 Received: by mail-qt0-f178.google.com with SMTP id x54so8173834qth.12 for <28620@debbugs.gnu.org>; Wed, 11 Oct 2017 11:50:16 -0700 (PDT) X-Gm-Message-State: AMCzsaXl2Vof+XAN06wxQGSi8ObQXsxaU3zSbzzp5V3F/I7DtuxPU1E1 2ez+IQ9tMSoLfdSWYKRgQIIysodHM7Jrm2ujbOo= X-Google-Smtp-Source: AOwi7QC5n5oqbLxy6Lw/DYibWjJQspkcUbhmDMHkQwhVptCyHNLm85s1AuWNIOdklMDKFFZ8yqIclSNVLQqeM/jvEMs= X-Received: by 10.237.59.249 with SMTP id s54mr1059338qte.34.1507747816493; Wed, 11 Oct 2017 11:50:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.34.225 with HTTP; Wed, 11 Oct 2017 11:49:45 -0700 (PDT) In-Reply-To: References: <83wp4e3nvx.fsf@gnu.org> <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <83vajwytja.fsf@gnu.org> <83poa4yqyq.fsf@gnu.org> <83376qouoj.fsf@gnu.org> From: Robert Weiner Date: Wed, 11 Oct 2017 14:49:45 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records wrong release window To: Eli Zaretskii , martin rudalics , Alan Third , 28620@debbugs.gnu.org Content-Type: multipart/alternative; boundary="94eb2c0e6e320355b2055b49e551" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 28620 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rswgnu@gmail.com Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.5 (----) --94eb2c0e6e320355b2055b49e551 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 11, 2017 at 1:16 PM, Robert Weiner wrote: > > =E2=80=8BMartin wrote:=E2=80=8B > >> Take the position of the event-end (if it's a frame) and translate it >> into absolute screen coordinates (the Elisp manual should give you >> enough clues to do that). Or, try =E2=80=98mouse-absolute-pixel-positio= n=E2=80=99 - it >> should give you the screen position of the mouse at that time so you can >> ignore the event completely. >> >> Then walk all your windows and compare that position with whatever >> =E2=80=98window-absolute-pixel-edges=E2=80=99 returns for that window. = If you have two >> or more positives, run =E2=80=98frame-list-z-order=E2=80=99 and compare = the result >> against those windows' frames. No hands, IMHO. >> =E2=80=8B=E2=80=8B >> > =E2=80=8B=E2=80=8B =E2=80=8B Eli wrote: =E2=80=8B=E2=80=8B Why cannot you compute the frame at button release using the a =E2=80=8B=E2=80=8B lgorithm proposed by Martin, given the mouse position at button release?=E2= =80=8B > >> =E2=80=8B=E2=80=8B >> > I w > =E2=80=8B=E2=80=8B > rote: > =E2=80=8B > =E2=80=8B=E2=80=8B > frame-list-z-order is Emacs 26 only; I need something that works with > older versions.=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > I'll see if I can make this work under Emacs 26 and then we can > contemplate a solution that would apply to earlier versions. > =E2=80=8B=E2=80=8B > Thanks for the reminder. It does still seem to me that there should be a > function that takes a mouse position and returns > =E2=80=8B=E2=80=8B > the top-most Emacs window that the position is in or nil. I'll work on i= t. > =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8B=E2=80=8BAnd now there is such a function. It was easier= than I expected thanks to Martin's pointers. Now how can we make this work (replacing frame-list-z-order) for Emacs versions prior to 26? -- Bob (defun window-at-absolute-pixel-position (&optional position) "Return the top-most Emacs window at optional POSITION ((X . Y) in pixels) or mouse position. If POSITION is not in a window, return nil. Considers all windows on the the same terminal display as the selected frame." (interactive) (setq position (or position (mouse-absolute-pixel-position))) (let* ((top-to-bottom-frames (frame-list-z-order)) (pos-x (car position)) (pos-y (cdr position)) edges left top right bottom frame in-frame window) ;; First find top-most frame containing position. (while (and (not in-frame) top-to-bottom-frames) (setq frame (car top-to-bottom-frames) top-to-bottom-frames (cdr top-to-bottom-frames)) ;; Check that in-frame is valid with frame-live-p since under macOS ;; when position is outside a frame, in-frame could be invalid and ;; frame-visible-p would trigger an error in that case. (when (and (frame-live-p frame) (frame-visible-p frame)) (setq edges (frame-edges frame) left (nth 0 edges) top (nth 1 edges) right (nth 2 edges) bottom (nth 3 edges)) (when (and (>=3D pos-x left) (<=3D pos-x right) (>=3D pos-y top) (<=3D pos-y bottom)) (setq in-frame frame)))) ;; If in-frame is found, find which of its windows contains ;; position and return that. The window-at call below requires ;; character coordinates relative to in-frame, so compute them. (setq pos-x (/ (- pos-x left) (frame-char-width in-frame)) pos-y (/ (- pos-y top) (frame-char-height in-frame)) window (window-at pos-x pos-y in-frame)) (if (called-interactively-p 'interactive) (message "%s at absolute pixel position %s" (or window "No Emacs window") position)) window)) --94eb2c0e6e320355b2055b49e551 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 11, 2= 017 at 1:16 PM, Robert Weiner <rsw= @gnu.org> wrote:=

=E2=80=8BMartin wrote:=E2=80=8B
Take the position of the event-end (if it's a frame) and tra= nslate it
into absolute screen coordinates (the Elisp manual should give= you
enough clues to do that).=C2=A0 Or, try =E2=80=98mouse-absolute-pix= el-position=E2=80=99 - it
should give you the screen position of th= e mouse at that time so you can
ignore the event completely.

Then= walk all your windows and compare that position with whatever
=E2=80=98= window-absolute-pixel-edges=E2=80=99 returns for that window.=C2=A0 If you = have two
or more positives, run =E2=80=98frame-list-z-order=E2=80=99 and= compare the result
against those windows' frames.=C2=A0 No hands, I= MHO.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=C2=A0
=E2=80=8B=C2=A0 Eli wrote:
=C2=A0 =C2=A0 =E2=80=8B=E2=80=8B
Why cannot you c= ompute the frame at button release using the a
=E2=80=8B=E2=80=8B=
lgorithm
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0proposed by Martin, given the mouse position at button releas= e?=E2=80=8B
=C2=A0
=C2=A0=E2=80=8B=E2=80=8B
I w
=E2=80=8B=E2=80=8B
rote:
= =C2=A0 =E2=80=8B
=E2=80=8B=E2=80=8B
frame-list-z-order is Em= acs 26 only; I need something that works with older versions.=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
I'll see if I can ma= ke this work under Emacs 26 and then we can contemplate a solution that wou= ld apply to earlier versions.
=E2=80=8B=E2=80=8B
Thanks for the reminder.=C2=A0 It does still see= m to me that there should be a function that takes a mouse position and ret= urns
=E2=80=8B=E2=80=8Bthe top-most Emacs window that the position is in or nil.=C2=A0 I'll = work on it.
=E2=80=8B=E2=80=8B
= =E2=80=8B=E2=80=8B=E2=80=8BAnd now there is such a function.=C2=A0 It was e= asier than I expected thanks to Martin's pointers.=C2=A0 Now how can we= make this work (replacing frame-list-z-order) for Emacs versions prior to = 26?=C2=A0 -- Bob

(def= un window-at-absolute-pixel-position (&optional position)
=C2=A0 "Return the top-most Emacs window at optio= nal POSITION ((X . Y) in pixels) or mouse position.
If POSITION is not in a window, return nil.=C2=A0 Considers all = windows on the the same terminal
display = as the selected frame."
=C2=A0 (inte= ractive)
=C2=A0 (setq position (or positi= on (mouse-absolute-pixel-position)))
=C2= =A0 (let* ((top-to-bottom-frames (frame-list-z-order))
(pos-x (car position= ))
(pos-y (cdr position))
edges left top right bottom
frame
in-frame
<= div class=3D"gmail_default"> window= )
=C2=A0 =C2=A0 ;; First find top-most fr= ame containing position.
=C2=A0 =C2=A0 (w= hile (and (not in-frame) top-to-bottom-frames)
=C2=A0 =C2=A0 =C2=A0 (setq frame (car top-to-bottom-frames)
=C2=A0 =C2= =A0 top-to-bottom-frames (cdr top-to-bottom-frames))
=C2=A0 =C2=A0 =C2=A0 ;; Check that in-frame is valid with frame= -live-p since under macOS
=C2=A0 =C2=A0 = =C2=A0 ;; when position is outside a frame, in-frame could be invalid and
=C2=A0 =C2=A0 =C2=A0 ;; frame-visible-p wo= uld trigger an error in that case.
=C2=A0= =C2=A0 =C2=A0 (when (and (frame-live-p frame) (frame-visible-p frame))
(set= q edges (frame-edges frame)
=C2=A0 =C2=A0 =C2=A0 left=C2=A0 =C2=A0(nth 0 e= dges)
=C2=A0 =C2=A0 =C2=A0 top=C2=A0 =C2=A0 (nth 1 edges)
=C2=A0 =C2=A0 =C2= =A0 right=C2=A0 (nth 2 edges)
=C2=A0 =C2=A0 =C2=A0 bottom (nth 3 edges))
(whe= n (and (>=3D pos-x left) (<=3D pos-x right)
=C2=A0 =C2=A0(>=3D pos= -y top)=C2=A0 (<=3D pos-y bottom))
=C2=A0 (setq in-frame frame))))
<= div class=3D"gmail_default">=C2=A0 =C2=A0 ;; If in-frame is found, find whi= ch of its windows contains
=C2=A0 =C2=A0 = ;; position and return that.=C2=A0 The window-at call below requires
<= div class=3D"gmail_default">=C2=A0 =C2=A0 ;; character coordinates relative= to in-frame, so compute them.
=C2=A0 =C2= =A0 (setq pos-x (/ (- pos-x left) (frame-char-width in-frame))
=C2=A0 pos-y = (/ (- pos-y top) (frame-char-height in-frame))
=C2=A0 window (window-at pos-= x pos-y in-frame))
=C2=A0 =C2=A0 (if (cal= led-interactively-p 'interactive)
=C2=A0 (message "%s at absolute p= ixel position %s"
=C2=A0 =C2=A0(or window "No Emacs window")= position))
=C2=A0 =C2=A0 window))
<= /div>
--94eb2c0e6e320355b2055b49e551-- From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 11 21:35:56 2017 Received: (at 28620) by debbugs.gnu.org; 12 Oct 2017 01:35:56 +0000 Received: from localhost ([127.0.0.1]:34656 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2SPj-0001mg-IS for submit@debbugs.gnu.org; Wed, 11 Oct 2017 21:35:56 -0400 Received: from eggs.gnu.org ([208.118.235.92]:48243) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2SPi-0001mR-4F for 28620@debbugs.gnu.org; Wed, 11 Oct 2017 21:35:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e2SPZ-00023q-M6 for 28620@debbugs.gnu.org; Wed, 11 Oct 2017 21:35:48 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE, RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34724) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2SPZ-00023Z-Gy for 28620@debbugs.gnu.org; Wed, 11 Oct 2017 21:35:45 -0400 Received: from mail-qt0-f181.google.com ([209.85.216.181]:51698) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1e2SPZ-00016d-3F for 28620@debbugs.gnu.org; Wed, 11 Oct 2017 21:35:45 -0400 Received: by mail-qt0-f181.google.com with SMTP id q4so10838649qtq.8 for <28620@debbugs.gnu.org>; Wed, 11 Oct 2017 18:35:45 -0700 (PDT) X-Gm-Message-State: AMCzsaXo1a2lcF4F/7ck/iRtzSKsRApnnz6WRV5Eq9P6PGd9EeN0uzq2 e8dGy6HuNo6khz2cFQ6mSzJaWRnNEOY3LWB/GA4= X-Google-Smtp-Source: AOwi7QD5fp18DoOQHTnPnieU70l4vkimlqewJOgNxJ0fYEYJhgr005d0NvWxEBFN/sLrMwbPbAdybcykEqxN0/Mnees= X-Received: by 10.200.48.74 with SMTP id g10mr1368275qte.121.1507772144632; Wed, 11 Oct 2017 18:35:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.34.225 with HTTP; Wed, 11 Oct 2017 18:35:13 -0700 (PDT) In-Reply-To: References: <83wp4e3nvx.fsf@gnu.org> <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <83vajwytja.fsf@gnu.org> <83poa4yqyq.fsf@gnu.org> <83376qouoj.fsf@gnu.org> From: Robert Weiner Date: Wed, 11 Oct 2017 21:35:13 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records wrong release window To: Eli Zaretskii , martin rudalics , Alan Third , 28620@debbugs.gnu.org Content-Type: multipart/alternative; boundary="001a113a0518154d2a055b4f8f22" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 28620 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rswgnu@gmail.com Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.5 (----) --001a113a0518154d2a055b4f8f22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I now have drags working across frames (after manipulating the drag button release event data to include the proper window and coordinates, though only in Lisp right now). As shown in the last message, I also have a function that finds the proper Emacs window given some display coordinates. The only remaining problem seems to be that none of this accounts for external application windows that may be obscuring an Emacs frame. So if I have 2 frames, f1 and f2, and a Chrome web browser window that is atop f2, then if I drag from f1 into Chrome above f2, my drag release code reports that the release window is in f2 rather than nil, as it should be. I am on macOS which uses click to focus, so Emacs still gets the release event since Chrome has not been selected with a click. Is there any way to deal with external window z-order layering such that one can tell within Emacs whether the topmost OS-level window at an absolute mouse position is an Emacs frame or not? Thanks, Bob On Wed, Oct 11, 2017 at 2:49 PM, Robert Weiner wrote: > On Wed, Oct 11, 2017 at 1:16 PM, Robert Weiner wrote: > >> >> =E2=80=8BMartin wrote:=E2=80=8B >> >>> Take the position of the event-end (if it's a frame) and translate it >>> into absolute screen coordinates (the Elisp manual should give you >>> enough clues to do that). Or, try =E2=80=98mouse-absolute-pixel-positi= on=E2=80=99 - it >>> should give you the screen position of the mouse at that time so you ca= n >>> ignore the event completely. >>> >>> Then walk all your windows and compare that position with whatever >>> =E2=80=98window-absolute-pixel-edges=E2=80=99 returns for that window. = If you have two >>> or more positives, run =E2=80=98frame-list-z-order=E2=80=99 and compare= the result >>> against those windows' frames. No hands, IMHO. >>> =E2=80=8B=E2=80=8B >>> >> =E2=80=8B=E2=80=8B > > =E2=80=8B Eli wrote: > =E2=80=8B=E2=80=8B > Why cannot you compute the frame at button release using the a > =E2=80=8B=E2=80=8B > lgorithm > proposed by Martin, given the mouse position at button release?= =E2=80=8B > > >> >>> =E2=80=8B=E2=80=8B >>> >> I w >> =E2=80=8B=E2=80=8B >> rote: >> =E2=80=8B >> =E2=80=8B=E2=80=8B >> frame-list-z-order is Emacs 26 only; I need something that works with >> older versions.=E2=80=8B >> =E2=80=8B=E2=80=8B >> =E2=80=8B=E2=80=8B >> I'll see if I can make this work under Emacs 26 and then we can >> contemplate a solution that would apply to earlier versions. >> =E2=80=8B=E2=80=8B >> Thanks for the reminder. It does still seem to me that there should be = a >> function that takes a mouse position and returns >> =E2=80=8B=E2=80=8B >> the top-most Emacs window that the position is in or nil. I'll work on >> it. >> > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B=E2=80=8BAnd now there is such a function. It was easi= er than I expected thanks > to Martin's pointers. Now how can we make this work (replacing > frame-list-z-order) for Emacs versions prior to 26? -- Bob > > (defun window-at-absolute-pixel-position (&optional position) > "Return the top-most Emacs window at optional POSITION ((X . Y) in > pixels) or mouse position. > If POSITION is not in a window, return nil. Considers all windows on the > the same terminal > display as the selected frame." > (interactive) > (setq position (or position (mouse-absolute-pixel-position))) > (let* ((top-to-bottom-frames (frame-list-z-order)) > (pos-x (car position)) > (pos-y (cdr position)) > edges left top right bottom > frame > in-frame > window) > ;; First find top-most frame containing position. > (while (and (not in-frame) top-to-bottom-frames) > (setq frame (car top-to-bottom-frames) > top-to-bottom-frames (cdr top-to-bottom-frames)) > ;; Check that in-frame is valid with frame-live-p since under macOS > ;; when position is outside a frame, in-frame could be invalid and > ;; frame-visible-p would trigger an error in that case. > (when (and (frame-live-p frame) (frame-visible-p frame)) > (setq edges (frame-edges frame) > left (nth 0 edges) > top (nth 1 edges) > right (nth 2 edges) > bottom (nth 3 edges)) > (when (and (>=3D pos-x left) (<=3D pos-x right) > (>=3D pos-y top) (<=3D pos-y bottom)) > (setq in-frame frame)))) > ;; If in-frame is found, find which of its windows contains > ;; position and return that. The window-at call below requires > ;; character coordinates relative to in-frame, so compute them. > (setq pos-x (/ (- pos-x left) (frame-char-width in-frame)) > pos-y (/ (- pos-y top) (frame-char-height in-frame)) > window (window-at pos-x pos-y in-frame)) > (if (called-interactively-p 'interactive) > (message "%s at absolute pixel position %s" > (or window "No Emacs window") position)) > window)) > --001a113a0518154d2a055b4f8f22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I now have drags working across frames (after manipulating the= drag button release event data to include the proper window and coordinate= s, though only in Lisp right now).=C2=A0 As shown in the last message, I al= so have a function that finds the proper Emacs window given some display co= ordinates.=C2=A0 The only remaining problem seems to be that none of this a= ccounts for external application windows that may be obscuring an Emacs fra= me.

So if I have 2 frames, f1 and f2, and a Chrome web browser windo= w that is atop f2, then if I drag from f1 into Chrome above f2, my drag rel= ease code reports that the release window is in f2 rather than nil, as it s= hould be.=C2=A0 I am on macOS which uses click to focus, so Emacs still get= s the release event since Chrome has not been selected with a click.
<= div class=3D"gmail_default" style=3D"font-family:monospace,monospace">
<= /div>
Is there any way to deal with external window z-order layering such that o= ne can tell within Emacs whether the topmost OS-level window at an absolute= mouse position is an Emacs frame or not?

Thanks,

Bob


On Wed,= Oct 11, 2017 at 2:49 PM, Robert Weiner <rsw@gnu.org> wrote:
On Wed, Oct 11, 2017 at 1:16 PM, Robert Wein= er <rsw@gnu.org> wrote:

=E2=80=8BMartin wrote:=E2=80=8B
=
Take the position of the ev= ent-end (if it's a frame) and translate it
into absolute screen coor= dinates (the Elisp manual should give you
enough clues to do that).=C2= =A0 Or, try =E2=80=98mouse-absolute-pixel-position=E2=80=99 - it
sh= ould give you the screen position of the mouse at that time so you can
i= gnore the event completely.

Then walk all your windows and compare t= hat position with whatever
=E2=80=98window-absolute-pixel-edges=E2=80=99= returns for that window.=C2=A0 If you have two
or more positives, run = =E2=80=98frame-list-z-order=E2=80=99 and compare the result
against thos= e windows' frames.=C2=A0 No hands, IMHO.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=C2=A0
=E2=80=8B=C2=A0 Eli wrote:
<= div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displa= y:inline">=C2=A0 =C2=A0 =E2=80=8B=E2=80=8B
Why cannot you compute the = frame at button release using the a
=E2=80=8B=E2=80=8B
lgori= thm
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0proposed by Martin, given the mouse position at button release?= =E2=80=8B
=C2=A0
=C2=A0
=E2=80=8B=E2=80=8B
I w
=E2=80=8B=E2=80=8B
rote:
<= /span>
=C2=A0 =E2=80=8B=E2=80=8B=E2=80=8B
frame-list-z-order is Emacs 26 only; I need = something that works with older versions.=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
I'll see if I can make this work under E= macs 26 and then we can contemplate a solution that would apply to earlier = versions.
=E2=80=8B=E2=80= =8B
Thanks for the reminder.=C2=A0 It does still seem to me that there= should be a function that takes a mouse position and returns
=E2=80=8B=E2=80=8B
the top-most Ema= cs window that the position is in or nil.=C2=A0 I'll work on it.
<= /span>
=E2=80=8B=E2=80=8B
=E2=80=8B= =E2=80=8B=E2=80=8BAnd now there is such a function.=C2=A0 It was easier tha= n I expected thanks to Martin's pointers.=C2=A0 Now how can we make thi= s work (replacing frame-list-z-order) for Emacs versions prior to 26?=C2=A0= -- Bob

(defun window= -at-absolute-pixel-position (&optional position)
=C2=A0 "Return the top-most Emacs window at optiona= l POSITION ((X . Y) in pixels) or mouse position.
If POSITION is not in a window, return nil.=C2=A0 Considers all wi= ndows on the the same terminal
display as= the selected frame."
=C2=A0 (intera= ctive)
=C2=A0 (setq position (or position= (mouse-absolute-pixel-position)))
= =C2=A0 (let* ((top-to-bottom-frames (frame-list-z-order))
(pos-x (ca= r position))
(pos-y (cdr position))
= edges left top right bottom
frame
in-frame
window)
=C2= =A0 =C2=A0 ;; First find top-most frame containing position.
=C2=A0 =C2=A0 (while (and (not in-frame) top-to-bottom-= frames)
=C2=A0 =C2=A0 =C2=A0 (setq frame = (car top-to-bottom-frames)
=C2=A0 =C2=A0 top-to-bottom-frames (cdr top-= to-bottom-frames))
=C2=A0 =C2=A0 =C2=A0 ;= ; Check that in-frame is valid with frame-live-p since under macOS
=C2=A0 =C2=A0 =C2=A0 ;; when position is outside = a frame, in-frame could be invalid and
= =C2=A0 =C2=A0 =C2=A0 ;; frame-visible-p would trigger an error in that case= .
=C2=A0 =C2=A0 =C2=A0 (when (and (frame-= live-p frame) (frame-visible-p frame))
(setq edges (frame-edges frame)<= /div>
=C2=A0 =C2=A0 =C2=A0 left=C2=A0 =C2=A0(nth 0 edges)
=C2=A0 =C2=A0 = =C2=A0 top=C2=A0 =C2=A0 (nth 1 edges)
=C2=A0 =C2=A0 =C2=A0 right=C2=A0 = (nth 2 edges)
=C2=A0 =C2=A0 =C2=A0 bottom (nth 3 edges))
(when (and= (>=3D pos-x left) (<=3D pos-x right)
=C2=A0 =C2=A0(>=3D pos-= y top)=C2=A0 (<=3D pos-y bottom))
=C2=A0 (setq in-frame frame))))
=C2=A0 =C2=A0 ;; If in-frame is found, find= which of its windows contains
=C2=A0 =C2= =A0 ;; position and return that.=C2=A0 The window-at call below requires
=C2=A0 =C2=A0 ;; character coordinates rela= tive to in-frame, so compute them.
=C2=A0= =C2=A0 (setq pos-x (/ (- pos-x left) (frame-char-width in-frame))
=C2= =A0 pos-y (/ (- pos-y top) (frame-char-height in-frame))
=C2=A0 window = (window-at pos-x pos-y in-frame))
=C2=A0 = =C2=A0 (if (called-interactively-p 'interactive)
=C2=A0 (message &q= uot;%s at absolute pixel position %s"
=C2=A0 =C2=A0(or window &qu= ot;No Emacs window") position))
=C2= =A0 =C2=A0 window))

--001a113a0518154d2a055b4f8f22-- From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 11 21:47:58 2017 Received: (at 28620) by debbugs.gnu.org; 12 Oct 2017 01:47:58 +0000 Received: from localhost ([127.0.0.1]:34664 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2SbO-00025P-B4 for submit@debbugs.gnu.org; Wed, 11 Oct 2017 21:47:58 -0400 Received: from eggs.gnu.org ([208.118.235.92]:53005) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2SbM-00025C-NV for 28620@debbugs.gnu.org; Wed, 11 Oct 2017 21:47:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e2SbE-0001AF-IT for 28620@debbugs.gnu.org; Wed, 11 Oct 2017 21:47:51 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE, RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34847) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2SbE-00019r-Ea for 28620@debbugs.gnu.org; Wed, 11 Oct 2017 21:47:48 -0400 Received: from mail-qt0-f170.google.com ([209.85.216.170]:54536) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1e2SbE-0004Lh-1U for 28620@debbugs.gnu.org; Wed, 11 Oct 2017 21:47:48 -0400 Received: by mail-qt0-f170.google.com with SMTP id z19so10868519qtg.11 for <28620@debbugs.gnu.org>; Wed, 11 Oct 2017 18:47:47 -0700 (PDT) X-Gm-Message-State: AMCzsaWPdUg+Ng9MEpQULzHAmnqvpW2KhnThJ+0DCIJ+K8s+n+Y9X8pr xNa6jgdLoeUNa7r3/vzQzd0abqjt/kPY2pcKRB0= X-Google-Smtp-Source: ABhQp+T99ACZy8SK37n4DVmQqcaOXn7We11LL3jThnrd9aAuHAEcX3pc74EDzEzRde8U+cMUElMFoq7SFjwxQ0XcYoU= X-Received: by 10.55.25.85 with SMTP id k82mr1210955qkh.223.1507772867597; Wed, 11 Oct 2017 18:47:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.37.243 with HTTP; Wed, 11 Oct 2017 18:47:16 -0700 (PDT) In-Reply-To: References: <83wp4e3nvx.fsf@gnu.org> <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <83vajwytja.fsf@gnu.org> <83poa4yqyq.fsf@gnu.org> <83376qouoj.fsf@gnu.org> From: Robert Weiner Date: Wed, 11 Oct 2017 21:47:16 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records wrong release window To: Eli Zaretskii , martin rudalics , Alan Third , 28620@debbugs.gnu.org Content-Type: multipart/alternative; boundary="001a11473a842cdc0f055b4fba30" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 28620 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rswgnu@gmail.com Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.5 (----) --001a11473a842cdc0f055b4fba30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 11, 2017 at 9:35 PM, Robert Weiner wrote: > > Is there any way to deal with external window z-order layering such that > one can tell within Emacs whether the topmost OS-level window at an > absolute mouse position is an Emacs frame or not? > =E2=80=8BOne idea is to expand frame-list-z-order with a 2nd optional argum= ent of all-display-windows-flag which when non-nil would include all of the OS-level windows in the returned list. Maybe a new object type or frame-variant is needed for this. Then just add another function that returns the edge coordinates for such windows and we could account for them in any z-ordering computations. What do you think? Bob =E2=80=8B --001a11473a842cdc0f055b4fba30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 11, 2= 017 at 9:35 PM, Robert Weiner <rsw= @gnu.org> wrote:=

Is= there any way to deal with external window z-order layering such that one = can tell within Emacs whether the topmost OS-level window at an absolute mo= use position is an Emacs frame or not?

= =E2=80=8BOne idea is to expand frame-list-z-order with a 2nd optional argum= ent of all-display-windows-flag which when non-nil would include all of the= OS-level windows in the returned list.=C2=A0 Maybe a new object type or fr= ame-variant is needed for this.=C2=A0 Then just add another function that r= eturns the edge coordinates for such windows and we could account for them = in any z-ordering computations.=C2=A0 What do you think?

Bob
=E2=80= =8B
--001a11473a842cdc0f055b4fba30-- From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 12 04:06:23 2017 Received: (at 28620) by debbugs.gnu.org; 12 Oct 2017 08:06:23 +0000 Received: from localhost ([127.0.0.1]:34828 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2YVb-0005bv-4M for submit@debbugs.gnu.org; Thu, 12 Oct 2017 04:06:23 -0400 Received: from mout.gmx.net ([212.227.15.15]:59073) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2YVZ-0005bh-0z for 28620@debbugs.gnu.org; Thu, 12 Oct 2017 04:06:21 -0400 Received: from [192.168.1.100] ([46.125.250.116]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MHoWj-1dyzjN0JJd-003eCA; Thu, 12 Oct 2017 10:06:04 +0200 Message-ID: <59DF2260.5030204@gmx.at> Date: Thu, 12 Oct 2017 10:05:52 +0200 From: martin rudalics MIME-Version: 1.0 To: rswgnu@gmail.com, Eli Zaretskii , Alan Third , 28620@debbugs.gnu.org Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records wrong release window References: <83wp4e3nvx.fsf@gnu.org> <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <83vajwytja.fsf@gnu.org> <83poa4yqyq.fsf@gnu.org> <83376qouoj.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:svhNR9CoxT8yHB5Tg+GMOjo6s2y0PSH5nzoxVlqlRWXAZY9S1qb d/8C8TpyxcaAl3bJmavKIyhy6vKbSuNf1ysuKx1OpK3qncSvUQ5JUFXOApb/evkJTzo+ibj bOSBuvQzGL06XVCkdG7lHtlqI7BMmRuFH/JvI2QMJGHDT72jUxExmcrjUGwok0KLX1yc/Rb V3Rmn/fQJpKCxUE++mFmQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:lVNrpQNU9MI=:k5/5hqyCdqZhtn6/XrNZe1 4AqWN319mHmc2LrQxeJvwUKcAYmP3kGtb98PguGgSuIR3ER3m7jYzI6bCTx/s/ID9l1GsKi/M ivRgv80amnZcl8hsMggnEBfMclT4PR2tYog+z5Tk+riQFqszDta8BKqoUSTG6T4z4t5CeoXfa g6YhKc+rsR8D/DSv+vp1EIuv8KLgq6dHTPtXQ1EXUT3hi/5Y5SmuvHVWWi/dXDwIYJFQDjFIa kME8l0yA3M/8pJnC2Nm0Tog9sMNZU9u2lkyAMVBqj1PKFvnpFpVP+YwslRgpyyxsyPsBr0KGZ UmJohGSCRN6JVZqllP+tnqqBr96y+7lH4y3c3ZoWZ69ZOQMCgMPToTcbmX4OVO7Xm3tbxPFa8 M6UuuhXKPT92tl42d6nIsFfEwLcLhSeFIsTU5kJNTZo49RotxAwGPEcFjU2b6+4+FtjH2+5zC yFsMIM+iW9wAIDyX0cDtKqH4uR07AlHl0qY+DomyjUzP2jPjy/X4RprdaiaYsRsT7G1aK5msU uwmuAgq9coDAeot8PPWshYVbEkxspWrd2RthyOIhN84apcuKIztgLWOqYtULj+AzZXreu/51m TT2isZNIur9QxLtJK5G+/H75JdgcV7vV3twZi0UEE+rR0oMZIrIG93zCIQUs0pDdlabg7mVQV bggooToyztumOwIZjK1KhvYNEJz1xNZS9lFZyv16gDTYCKVmma6gHfd5X8yYdoXerZ8SLHrZj zbvqPLC7E8+/Mt0zl7+kJcWP92vEoewq0g9yczncj2h2jPzdutzK8unj0odvFynYhJIUY3ghG F/AiS7mITTlORM4EhrW8dvjpIllPXjvq+F6lS0QyOKkmIutDoeDiflbMEYR7BhX0ZXrdDOK X-Spam-Score: 4.9 (++++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > So if I have 2 frames, f1 and f2, and a Chrome web browser window that is > atop f2, then if I drag from f1 into Chrome above f2, my drag release code > reports that the release window is in f2 rather than nil, as it should be. > I am on macOS which uses click to focus, so Emacs still gets the release > event since Chrome has not been selected with a click. [...] Content analysis details: (4.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [46.125.250.116 listed in dnsbl.sorbs.net] 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [212.227.15.15 listed in dnsbl.sorbs.net] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [46.125.250.116 listed in zen.spamhaus.org] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.15.15 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) X-Debbugs-Envelope-To: 28620 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 4.9 (++++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > So if I have 2 frames, f1 and f2, and a Chrome web browser window that is > atop f2, then if I drag from f1 into Chrome above f2, my drag release code > reports that the release window is in f2 rather than nil, as it should be. > I am on macOS which uses click to focus, so Emacs still gets the release > event since Chrome has not been selected with a click. [...] Content analysis details: (4.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [46.125.250.116 listed in dnsbl.sorbs.net] 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [212.227.15.15 listed in dnsbl.sorbs.net] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [46.125.250.116 listed in zen.spamhaus.org] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.15.15 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) > So if I have 2 frames, f1 and f2, and a Chrome web browser window that is > atop f2, then if I drag from f1 into Chrome above f2, my drag release code > reports that the release window is in f2 rather than nil, as it should be. > I am on macOS which uses click to focus, so Emacs still gets the release > event since Chrome has not been selected with a click. I would call this a feature: f2 is probably the one meaningful target of your operation at that screen position. > Is there any way to deal with external window z-order layering such that > one can tell within Emacs whether the topmost OS-level window at an > absolute mouse position is an Emacs frame or not? Not really. Compositing window managers on X no more allow to track the visibility of windows reliably. So while we can discern the visibility of our own (window manager) windows based on what we store in their asscociated frames' 'visible' slots, we can't do that for windows of other applications. And processing whatever else XGetWindowAttributes returns for another application's window might not be trivial either. It should be possible to do what you want on Windows (where the debugger also notifies you when an Emacs frame is obscured) though. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 12 09:09:13 2017 Received: (at 28620) by debbugs.gnu.org; 12 Oct 2017 13:09:13 +0000 Received: from localhost ([127.0.0.1]:35006 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2dEf-0006vc-Cg for submit@debbugs.gnu.org; Thu, 12 Oct 2017 09:09:13 -0400 Received: from eggs.gnu.org ([208.118.235.92]:51389) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2dEd-0006vN-Lb for 28620@debbugs.gnu.org; Thu, 12 Oct 2017 09:09:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e2dEU-0006AU-B3 for 28620@debbugs.gnu.org; Thu, 12 Oct 2017 09:09:06 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE, RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42553) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2dEU-0006AE-66 for 28620@debbugs.gnu.org; Thu, 12 Oct 2017 09:09:02 -0400 Received: from mail-qt0-f169.google.com ([209.85.216.169]:43793) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1e2dET-0005MT-T1 for 28620@debbugs.gnu.org; Thu, 12 Oct 2017 09:09:01 -0400 Received: by mail-qt0-f169.google.com with SMTP id j58so2365490qtj.0 for <28620@debbugs.gnu.org>; Thu, 12 Oct 2017 06:09:01 -0700 (PDT) X-Gm-Message-State: AMCzsaWsVqXCmgf7FJxPKssqwDR84Z+K5bMCPgA3PaIA5KxLNtrZcLhF gs8ESAJvQsdqo55Xi73BAeF5bRdZMKlE9+HDvRc= X-Google-Smtp-Source: ABhQp+T91ZbPv/4NHPxsgmBtpuZPhoOEvEdQdv8UQRWYXFA80zNjMmalIEt1oeSrd0mllW2cNs4oDaTRyKHk8oyQXzo= X-Received: by 10.200.54.220 with SMTP id b28mr3262346qtc.186.1507813741503; Thu, 12 Oct 2017 06:09:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.34.225 with HTTP; Thu, 12 Oct 2017 06:08:30 -0700 (PDT) In-Reply-To: <59DF2260.5030204@gmx.at> References: <83wp4e3nvx.fsf@gnu.org> <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <83vajwytja.fsf@gnu.org> <83poa4yqyq.fsf@gnu.org> <83376qouoj.fsf@gnu.org> <59DF2260.5030204@gmx.at> From: Robert Weiner Date: Thu, 12 Oct 2017 09:08:30 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records wrong release window To: martin rudalics Content-Type: multipart/alternative; boundary="001a113755ca73294c055b593e36" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 28620 Cc: Eli Zaretskii , Alan Third , 28620@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rswgnu@gmail.com Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.5 (----) --001a113755ca73294c055b593e36 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 12, 2017 at 4:05 AM, martin rudalics wrote: > > So if I have 2 frames, f1 and f2, and a Chrome web browser window that = is > > atop f2, then if I drag from f1 into Chrome above f2, my drag release > code > > reports that the release window is in f2 rather than nil, as it should > be. > > I am on macOS which uses click to focus, so Emacs still gets the releas= e > > event since Chrome has not been selected with a click. > > I would call this a feature: f2 is probably the one meaningful target of > your operation at that screen position. =E2=80=8BI think it is a feature that Emacs receives an event for this but = a defect that it can't distinguish when f2 is atop an external window or not and thus whether the event was actually directed at f2 or not. =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > Is there any way to deal with external window z-order layering such tha= t > =E2=80=8B=E2=80=8B > > one can tell within Emacs whether the topmost OS-level window at an > =E2=80=8B=E2=80=8B > > absolute mouse position is an Emacs frame or not? > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > Not really. Compositing window managers on X no more allow to track the > =E2=80=8B=E2=80=8B > visibility of windows reliably. So while we can discern the visibility > =E2=80=8B=E2=80=8B > of our own (window manager) windows based on what we store in their > =E2=80=8B=E2=80=8B > asscociated frames' 'visible' slots, we can't do that for windows of > =E2=80=8B=E2=80=8B > other applications. And processing whatever else XGetWindowAttributes > =E2=80=8B=E2=80=8B > returns for another application's window might not be trivial either. > =E2=80=8BJust FYI, I am using the macOS window manager, not X, though as yo= u note, it is an issue there too. The application-level window managers must have a z-ordering for all windows in order to be able to select and raise windows when they are behind others. So you are saying that they don't publish this information in any useful way that Emacs can obtain, right? Part of the issue is that the macOS window manager uses click-to-focus, so the release event of the drag does not switch focus to the application whose window the release falls upon. However, in drag-n-drop operations, the window manager automatically switches focus to any compatible application that the mouse moves over (after a delay) so that the right application receives the drop (based on Z-order). Mouse wheel events are also delivered to the topmost Z-order window without either raising the window or switching focus. So the window manager always knows where it should deliver at least two kinds of events and maybe one of those types of events could be used to help Emacs know whether a release event was over one of its frames or over the window of an another application. =E2=80=8B > > =E2=80=8B=E2=80=8B > It should be poss > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > ible to do what you want on Windows (where the debugger > =E2=80=8B=E2=80=8B > also notifies you > =E2=80=8B=E2=80=8B > when an Emacs frame is obscured) though. =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8BWell, one platform would be a good start.=E2=80=8B What = would the pseudo-code look like to check whether or not an Emacs frame was uppermost at the point of mouse release? Thanks, Bob --001a113755ca73294c055b593e36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Oct 12, 2= 017 at 4:05 AM, martin rudalics <rudalics@gmx.at> wrote:
> So if I have 2 f= rames, f1 and f2, and a Chrome web browser window that is
> atop f2, then if I drag from f1 into Chrome above f2, my drag release = code
> reports that the release window is in f2 rather than nil, as it should= be.
> I am on macOS which uses click to focus, so Emacs still gets the relea= se
> event since Chrome has not been selected with a click.

 I would call this a feature: f2 is probably the one meaningful target of your operation at that screen position.

=E2=80=8BI t= hink it is a feature that Emacs receives an event for this but a defect tha= t it can't distinguish when f2 is atop an external window or not and th= us whether the event was actually directed at f2 or not.

=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
> Is there any way to deal with exter= nal window z-order layering such that
=E2=80=8B=E2=80=8B
> one can tell within Emacs whether t= he topmost OS-level window at an
=E2=80=8B=E2=80=8B
> absolute mouse position is an Emacs= frame or not?
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
Not really.=C2=A0 Compositing window man= agers on X no more allow to track the
=E2=80=8B=E2=80=8B
visibility of windows reliably.=C2=A0 So= while we can discern the visibility
=E2=80=8B=E2=80=8B
of our own (window manager) windows base= d on what we store in their
=E2=80=8B=E2=80=8B
asscociated frames' 'visible'= ; slots, we can't do that for windows of
=E2=80=8B=E2=80=8B
other applications.=C2=A0 And processing= whatever else XGetWindowAttributes
=E2=80=8B=E2=80=8B
returns for another application's wi= ndow might not be trivial either.

=E2=80=8BJust = FYI, I am using the macOS window manager, not X, though as you note, it is = an issue there too.
The application-level window managers must have a z-or= dering for all windows in order to be able to select and raise windows when= they are behind others.=C2=A0 So you are saying that they don't publis= h this information in any useful way that Emacs can obtain, right?

P= art of the issue is that the macOS window manager uses click-to-focus, so t= he release event of the drag does not switch focus to the application whose= window the release falls upon.=C2=A0 However, in drag-n-drop operations, t= he window manager automatically switches focus to any compatible applicatio= n that the mouse moves over (after a delay) so that the right application r= eceives the drop (based on Z-order).

Mouse wheel events are also del= ivered to the topmost Z-order window without either raising the window or s= witching focus.

So the window manager always knows where it should d= eliver at least two kinds of events and maybe one of those types of events = could be used to help Emacs know whether a release event was over one of it= s frames or over the window of an another application.

=E2=80=8B

=E2=80=8B=E2=80=8B
It should be poss
=E2=80=8B=E2= =80=8B
=E2=80=8B=E2=80=8B
ible to do what you want on = Windows (where the debugger
=E2=80=8B=E2=80=8B
also notifies you
=E2=80=8B= =E2=80=8B
when an Emacs frame is obscured) though.
=E2=80= =8B=E2=80=8B
=E2=80=8B=E2=80=8BWell, one platform would be a good start.= =E2=80=8B=C2=A0 What would the pseudo-code look like to check whether or no= t an Emacs frame was uppermost at the point of mouse release?

= Thanks,

Bob

--001a113755ca73294c055b593e36-- From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 14 04:35:57 2017 Received: (at 28620) by debbugs.gnu.org; 14 Oct 2017 08:35:57 +0000 Received: from localhost ([127.0.0.1]:38762 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3HvJ-0002oG-9F for submit@debbugs.gnu.org; Sat, 14 Oct 2017 04:35:57 -0400 Received: from mout.gmx.net ([212.227.15.19]:61254) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3HvH-0002nu-GG for 28620@debbugs.gnu.org; Sat, 14 Oct 2017 04:35:56 -0400 Received: from [192.168.1.100] ([46.125.249.56]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MNYxW-1eARql10H4-007ECU; Sat, 14 Oct 2017 10:35:37 +0200 Message-ID: <59E1CC55.2090400@gmx.at> Date: Sat, 14 Oct 2017 10:35:33 +0200 From: martin rudalics MIME-Version: 1.0 To: rswgnu@gmail.com Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records wrong release window References: <83wp4e3nvx.fsf@gnu.org> <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <83vajwytja.fsf@gnu.org> <83poa4yqyq.fsf@gnu.org> <83376qouoj.fsf@gnu.org> <59DF2260.5030204@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:IUE2y/Q7pThXyl6N6OX+L1muBSGkK+jLGGHuk26FhqetWDYQb8G An+YdPufIXGO5rRWabqRC432V9A88MAnrZw65zYp5H9UzNZVfHsg1LUpqG585mToD5Amzlf sLDHPUK2HzAx4TYfQDLMEPBPXI1hlGEK0kFkEVbLlvkC3xh9TcQXVIJ4ny8twCcbztAJd40 B2id7guybHvrg7oVPooTw== X-UI-Out-Filterresults: notjunk:1;V01:K0:yOHegrsvI44=:ksk3BdDBFEvNFP7cMExKK/ xeVXEumdO8BXbxTqNUNwca/8625iHv5YbTL4+cDIweID13uDp8Chdmug0qsJkkdB5RzX9f0Np JJl8MkaZQtJgRXGD57LQbwBDxgdoc1EAUyd0HXs1GREywtio4SaVkuBgW+BwEGGWhLRL87bBq 9euG3gowS6eikPFw6NxG/vYrrwLTBwCObM+vGrz+KQwFP+bAQR5sr22JMzoVZLoizC3TdbYWx XFLEkruTmw1ryHjqBAQn1qtvgrBQXNjTNLOcdzwPKF7Hm/lyEqOqnTFiGofaYMeiED6D+9d4L 4Y8N/mDN1zbPkT3Osli3Z4efaIGbzdRIGAtUfj398va3pvU7GUB4rhl+wFEnu1aIp6IHnRrqL XRK+cvE/67fVdCo3D2dB/VMRtxNaVUuATj+1BDcI06mIhhZ6jq1AZqqXZ7XCfAIWCXOvkNis7 tKifpK80MMbIZ2yJctfTyLh23yaw+KA+2kNmq2Wpx2EL0yVWETXSwhUeVa7xwO3RjunzelVxA dpSygFe53RS0AZFWHAq/47zRbBI1jwHoUt7szGahPJlSxg6PBHJ8f9cDvm84WO1X1zhT70TaT NbgTux3KoR12lxYOX0pTIxcqlESAxGckGCRcpQTMeSilqQUd2t11bhMTFkMtD4U/1UCiPYuAj oXykBLoZVeOPzyjb1NUdhT6E4ZonrtyWk8QCbm/l2TZU9ImRXFRf5YlnBezuaN9+fo0nWI+un 3EMQw7kVU4mB2qSTILfp4uNZs2RpasKCcYBMmfLQoqiO6/QfPb8LMFrTm47RV7Lxrtoqx92pL 7DoTTL9AQfHhZWC1C9+HYwjTcKhwp47YRrUx6ftUxEeTz5QQiQig2o5wt0Pas6ik+M9NsXZ X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 28620 Cc: Eli Zaretskii , Alan Third , 28620@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) > =E2=80=8BI think it is a feature that Emacs receives an event for this= but a defect > that it can't distinguish when f2 is atop an external window or not an= d > thus whether the event was actually directed at f2 or not. =E2=80=98mouse-drag-region=E2=80=99 is an Emacs internal function, so it'= s no defect. If it were not internal, Emacs would have to be either able to poll the other window's application as to whether it supports dropping an Emacs internal string or convert that string to some appropriate coding that other applications understand. Neither of these has been done yet and it will be non-trivial to do that for our various platforms. > =E2=80=8BJust FYI, I am using the macOS window manager, not X, though = as you note, > it is an issue there too. > The application-level window managers must have a z-ordering for all > windows in order to be able to select and raise windows when they are > behind others. So you are saying that they don't publish this informa= tion > in any useful way that Emacs can obtain, right? All I can say is that when you nowadays try to obtain information on whether a window is really visible under X, chances are that you don't get it. Querying the z-order will only tell you something like "window Y cannot obscure window X because it's lower in the z-order". > Part of the issue is that the macOS window manager uses click-to-focus= , so > the release event of the drag does not switch focus to the application= > whose window the release falls upon. As Stefan already mentioned earlier: With a drag operation usually no focus shifting occurs anyway. > However, in drag-n-drop operations, > the window manager automatically switches focus to any compatible > application that the mouse moves over (after a delay) so that the righ= t > application receives the drop (based on Z-order). It's completely up to the window manager which polls the application(s) whether they are ready to receive the object to drop. Emacs is not involved in that process. It would be involved only to tell whether it would accept such a string when it's the target of a drop. > Mouse wheel events are also delivered to the topmost Z-order window wi= thout > either raising the window or switching focus. Mouse wheel events are completely different and highly window system dependent. Sometimes they get caught before Emacs sees them at all and get transformed to scroll bar thumb drag events to the owner of the scroll bar nearest to the mouse cursor at the time the wheel gets scrolled. > So the window manager always knows where it should deliver =2E.. it never "knows". Some make better guesses and some make worse ...= > What would the pseudo-code > look like to check whether or not an Emacs frame was uppermost at the = point > of mouse release? (1) =E2=80=98frame-list-z-order=E2=80=99 would have to be able to return = all windows on your system and (2) a function would be needed to get the attributes of those windows. martin From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 14 13:17:37 2017 Received: (at 28620) by debbugs.gnu.org; 14 Oct 2017 17:17:37 +0000 Received: from localhost ([127.0.0.1]:40464 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3Q48-0006jP-To for submit@debbugs.gnu.org; Sat, 14 Oct 2017 13:17:37 -0400 Received: from eggs.gnu.org ([208.118.235.92]:52425) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3Q47-0006jB-BY for 28620@debbugs.gnu.org; Sat, 14 Oct 2017 13:17:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e3Q3y-0001PX-Vj for 28620@debbugs.gnu.org; Sat, 14 Oct 2017 13:17:30 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE, RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47825) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e3Q3y-0001PF-Rr for 28620@debbugs.gnu.org; Sat, 14 Oct 2017 13:17:26 -0400 Received: from mail-qk0-f169.google.com ([209.85.220.169]:51469) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1e3Q3y-0001ig-FJ for 28620@debbugs.gnu.org; Sat, 14 Oct 2017 13:17:26 -0400 Received: by mail-qk0-f169.google.com with SMTP id 17so8428116qkq.8 for <28620@debbugs.gnu.org>; Sat, 14 Oct 2017 10:17:26 -0700 (PDT) X-Gm-Message-State: AMCzsaU73sO9Jy7bTlav+8Y3evvg9+KPFCNBwoV3Hd6hzKS0sKDczg/7 XQb0TkMe3iTjNW/0XE2lKpArXzlYWFaq0Bwk5Fc= X-Google-Smtp-Source: AOwi7QBVw1cGLvjksPfEmnHVllT55wzOxW+SZ2kwxRR0e37+i/qVB2OzP/SCFzXohYC4w2KT2SOEygwxxMe+5Lg9VEM= X-Received: by 10.55.12.130 with SMTP id 124mr7145855qkm.186.1508001445921; Sat, 14 Oct 2017 10:17:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.34.225 with HTTP; Sat, 14 Oct 2017 10:16:55 -0700 (PDT) In-Reply-To: <59E1CC55.2090400@gmx.at> References: <83wp4e3nvx.fsf@gnu.org> <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <83vajwytja.fsf@gnu.org> <83poa4yqyq.fsf@gnu.org> <83376qouoj.fsf@gnu.org> <59DF2260.5030204@gmx.at> <59E1CC55.2090400@gmx.at> From: Robert Weiner Date: Sat, 14 Oct 2017 13:16:55 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records wrong release window To: martin rudalics Content-Type: multipart/alternative; boundary="001a114d6da08149f4055b84f226" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 28620 Cc: Eli Zaretskii , Alan Third , 28620@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rswgnu@gmail.com Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.5 (----) --001a114d6da08149f4055b84f226 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Martin: Thanks for commenting on this and sharing some of your extensive knowledge on window event handling and Emacs. On Sat, Oct 14, 2017 at 4:35 AM, martin rudalics wrote: > > =E2=80=8BI think it is a feature that Emacs receives an event for this = but a > defect > > that it can't distinguish when f2 is atop an external window or not and > > thus whether the event was actually directed at f2 or not. > > =E2=80=98mouse-drag-region=E2=80=99 is an Emacs internal function, so it'= s no defect. > If it were not internal, Emacs would have to be either able to poll the > other window's application as to whether it supports dropping an Emacs > internal string or convert that string to some appropriate coding that > other applications understand. Neither of these has been done yet and > it will be non-trivial to do that for our various platforms. =E2=80=8BOk, that indicates that drag-and-drop from Emacs to external appli= cations is unlikely but it still leaves the issue of recognizing whether a drag release event maps to an Emacs frame or not (when the frame is covered by an external app's window). I already have code that recognizes this in Lisp; we should make it a primitive so the drag release code in Emacs could report more useful and accurate information in drag release events. I guess you are saying that Emacs drag events must start and end within Emacs frames. I think about it a bit differently. Since the mouse can move in and out of Emacs frames and release events can occur (in logical Z-ordered OS window space) outside of Emacs, yet still register with Emacs (when the release occurs within the geometry of a frame but the frame is covered by another app's window), I think Emacs event handling should return different information when the release frame is not the topmost OS-level window at the point of release. Then handler code could dispatch as necessary. I already have Lisp code doing useful things with such information (presently, I have to adjust the drag release event information). So I know it would be helpful to have this as default Emacs event reporting behavior. =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > =E2=80=8BJust FYI, I am using the macOS window manager, not X, though a= s you > note, > =E2=80=8B=E2=80=8B > > it is an issue there too. > =E2=80=8B=E2=80=8B > > The application-level window managers must have a z-ordering for all > =E2=80=8B=E2=80=8B > > windows in order to be able to select and raise windows when they are > =E2=80=8B=E2=80=8B > > behind others. So you are saying that they don't publish this > information > =E2=80=8B=E2=80=8B > > in any useful way that Emacs can obtain, right? > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > All I can say is that when you nowadays try to obtain information on > =E2=80=8B=E2=80=8B > whether a window is really visible under X, chances are that you don't > =E2=80=8B=E2=80=8B > g > =E2=80=8B=E2=80=8B > e > =E2=80=8B=E2=80=8B > t > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > i > =E2=80=8B=E2=80=8B > t > =E2=80=8B=E2=80=8B > . =E2=80=8BEach window has a 'visible' attribute. Are you saying this is not accurate these days?=E2=80=8B =E2=80=8B=E2=80=8B=E2=80=8B > =E2=80=8B > Querying the z-order will only tell you something like "window > =E2=80=8B=E2=80=8B > Y cannot obscure window X because it's lower in the z-order". =E2=80=8BWe just want to know when given a screen position whether an Emacs= frame is topmost at that position or not.=E2=80=8B =E2=80=8B=E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > Part of the issue is that the macOS window manager uses click-to-focus, > so > =E2=80=8B=E2=80=8B > > the release event of the drag does not switch focus to the application > =E2=80=8B=E2=80=8B > > whose window the release falls upon. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > As Stefan already mentioned earlier: With a drag operation usually no > =E2=80=8B=E2=80=8B > focus shifting occurs anyway. For the interactive things I am doing, I find that selecting the window of mouse release is always best but I agree it is not necessary in all instances. =E2=80=8B=E2=80=8B > > =E2=80=8B > > However, in drag-n-drop operations, > =E2=80=8B=E2=80=8B > > the window manager automatically switches focus to any compatible > =E2=80=8B=E2=80=8B > > application that the mouse moves over (after a delay) so that the right > =E2=80=8B=E2=80=8B > > application receives the drop (based on Z-order). > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > It's completely up to the window manager which polls the application(s) > =E2=80=8B=E2=80=8B > whether they are ready to receive the object to drop. Emacs is not > =E2=80=8B=E2=80=8B > involved in that process. It would be involved only to tell whether it > =E2=80=8B=E2=80=8B > would accept such a string when it's the target of a drop. =E2=80=8BI understand that. I was just noting that there is an example of = a drag release event handler that selects the window of release as a standard part of its operation. =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > Mouse wheel events are also delivered to the topmost Z-order window > without > =E2=80=8B=E2=80=8B > > either raising the window or switching focus. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > Mouse wheel events are completely different and highly window system > =E2=80=8B=E2=80=8B > dependent. Sometimes they get caught before Emacs sees them at all and > =E2=80=8B=E2=80=8B > get transformed to scroll bar thumb drag events to the owner of the > =E2=80=8B=E2=80=8B > scroll bar nearest to the mouse cursor at the time the wheel gets > =E2=80=8B=E2=80=8B > scrolled. =E2=80=8BAgain, I was just providing context of what might be possible base= d on other event handling that occurs already in Emacs under macOS.=E2=80=8B =E2=80=8B=E2=80=8B > > =E2=80=8B > =E2=80=8B=E2=80=8B > > So the window manager always knows where it should deliver > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > ... it never "knows". Some make better guesses and some make worse ... =E2=80=8BOn macOS the scroll wheel events seem to go to the right window 10= 0% of the time from what I have seen.=E2=80=8B =E2=80=8B=E2=80=8B > > =E2=80=8B > =E2=80=8B=E2=80=8B > > What would the pseudo-code > =E2=80=8B=E2=80=8B > > look like to check whether or not an Emacs frame was uppermost at the > point > =E2=80=8B=E2=80=8B > > of mouse release? > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > (1) =E2=80=98frame-list-z-order=E2=80=99 would have to be able to return = all windows on > =E2=80=8B=E2=80=8B > your system =E2=80=8BIs it likely we could build a multi-platform primitive =E2=80=8Bth= at would supply that information given what you have said? =E2=80=8B=E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > and (2) a function would be needed to get the attributes of > =E2=80=8B=E2=80=8B > those windows. =E2=80=8B2 seems straightforward. Bob =E2=80=8B=E2=80=8B --001a114d6da08149f4055b84f226 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Martin:
<= span style=3D"font-family:arial,sans-serif">
Thanks for commenting on this and sharing some o= f your extensive knowledge on window event handling and Emacs.
=

On Sat, Oct 14, 2017 at 4:35 AM, martin rudalics <rudalics@gmx.at> wrote:
> =E2=80=8BI think it is a feature that Emacs rece= ives an event for this but a defect
> that it can't distinguish when f2 is atop an external window or no= t and
> thus whether the event was actually directed at f2 or not.

 =E2=80=98mouse-drag-region=E2=80=99 is an Emacs internal function, so it= 9;s no defect.
If it were not internal, Emacs would have to be either able to poll the
other window's application as to whether it supports dropping an Emacs<= br> internal string or convert that string to some appropriate coding that
other applications understand.=C2=A0 Neither of these has been done yet and=
it will be non-trivial to do that for our various platforms.

=E2=80=8BOk, that indicates that drag-and-drop from Emacs to exter= nal applications is unlikely but it still leaves the issue of recognizing w= hether a drag release event maps to an Emacs frame or not (when the frame i= s covered by an external app's window).=C2=A0 I already have code that = recognizes this in Lisp; we should make it a primitive so the drag release = code in Emacs could report more useful and accurate information in drag rel= ease events.

I guess you are saying that Emacs drag events must star= t and end within Emacs frames.=C2=A0 I think about it a bit differently.=C2= =A0 Since the mouse can move in and out of Emacs frames and release events = can occur (in logical Z-ordered OS window space) outside of Emacs, yet stil= l register with Emacs (when the release occurs within the geometry of a fra= me but the frame is covered by another app's window), I think Emacs eve= nt handling should return different information when the release frame is n= ot the topmost OS-level window at the point of release.=C2=A0 Then handler = code could dispatch as necessary.

I already have Lisp code doing u= seful things with such information (presently, I have to adjust the drag re= lease event information).=C2=A0 So I know it would be helpful to have this = as default Emacs event reporting behavior.

=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
> =E2=80=8BJust FYI, I am using the m= acOS window manager, not X, though as you note,
=E2=80=8B=E2=80=8B
> it is an issue there too.
=E2=80=8B=E2=80=8B
> The application-level window manage= rs must have a z-ordering for all
=E2=80=8B=E2=80=8B
> windows in order to be able to sele= ct and raise windows when they are
=E2=80=8B=E2=80=8B
> behind others.=C2=A0 So you are say= ing that they don't publish this information
=E2=80=8B=E2=80=8B
> in any useful way that Emacs can ob= tain, right?
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
All I can say is that when you nowadays = try to obtain information on
=E2=80=8B=E2=80=8B
whether a window is really visible under= X, chances are that you don't
=E2=80=8B=E2=80=8B
g
=E2=80=8B=E2=80=8B
e=E2=80=8B=E2=80=8B
t
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
i
=E2=80=8B=E2=80=8B
t
=E2=80=8B=E2=80=8B
.

=E2=80=8BEach windo= w has a 'visible' attribute.=C2=A0 Are you saying this is not accur= ate these days?=E2=80=8B
=E2=80=8B=E2=80=8B=E2=80=8B
=E2=80=8B
=C2=A0 Querying the z-order = will only tell you something like "window
=E2=80=8B=E2=80=8B
Y cannot obscure window X because it'= ;s lower in the z-order".

=E2=80=8BWe ju= st want to know when given a screen position whether an Emacs frame is topm= ost at that position or not.=E2=80=8B
=E2=80=8B=E2=80=8B=E2=80=8B
=E2=80=8B=E2= =80=8B

=E2=80=8B=E2=80=8B
> Part of the issue i= s that the macOS window manager uses click-to-focus, so
=E2=80=8B=E2=80=8B
> the release event of the drag does = not switch focus to the application
=E2=80=8B=E2=80=8B
> whose window the release falls upon= .
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
As Stefan already mentioned earlier: Wit= h a drag operation usually no
=E2=80=8B=E2=80=8B
focus shifting occurs anyway.

For the interactive things I am doing, I find that selecting t= he window of mouse release is always best but I agree it is not necessary i= n all instances.

=E2=80=8B=E2=80=8B

=E2=80=8B
> However, in drag-n-drop operations,
=E2=80=8B=E2=80=8B
> the window manager automatically sw= itches focus to any compatible
=E2=80=8B=E2=80=8B
> application that the mouse moves ov= er (after a delay) so that the right
=E2=80=8B=E2=80=8B
> application receives the drop (base= d on Z-order).
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
It's completely up to the window man= ager which polls the application(s)
=E2=80=8B=E2=80=8B
whether they are ready to receive the ob= ject to drop.=C2=A0 Emacs is not
=E2=80=8B=E2=80=8B
involved in that process.=C2=A0 It would= be involved only to tell whether it
=E2=80=8B=E2=80=8B
would accept such a string when it's= the target of a drop.

=E2=80=8BI understand that.= =C2=A0 I was just noting that there is an example of a drag release event h= andler that selects the window of release as a standard part of its operati= on.

=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
> Mouse wheel events are also deliver= ed to the topmost Z-order window without
=E2=80=8B=E2=80=8B
> either raising the window or switch= ing focus.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
Mouse wheel events are completely differ= ent and highly window system
=E2=80=8B=E2=80=8B
dependent.=C2=A0 Sometimes they get caug= ht before Emacs sees them at all and
=E2=80=8B=E2=80=8B
get transformed to scroll bar thumb drag= events to the owner of the
=E2=80=8B=E2=80=8B
scroll bar nearest to the mouse cursor a= t the time the wheel gets
=E2=80=8B=E2=80=8B
scrolled.

=E2=80= =8BAgain, I was just providing context of what might be possible based on o= ther event handling that occurs already in Emacs under macOS.=E2=80=8B
=E2=80=8B= =E2=80=8B

=E2=80=8B
=E2=80=8B=E2=80=8B
> So the wi= ndow manager always knows where it should deliver
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
... it never "knows".=C2=A0 So= me make better guesses and some make worse ...

<= div class=3D"gmail_default" style=3D"font-family:monospace,monospace">=E2= =80=8BOn macOS the scroll wheel events seem to go to the right window 100% = of the time from what I have seen.=E2=80=8B

=E2=80=8B=E2=80=8B

=E2=80=8B
=E2=80=8B=E2=80=8B
> What woul= d the pseudo-code
=E2=80=8B=E2=80=8B
> look like to check whether or not a= n Emacs frame was uppermost at the point
=E2=80=8B=E2=80=8B
> of mouse release?
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
(1) =E2=80=98frame-list-z-order=E2=80=99= would have to be able to return all windows on
=E2=80=8B=E2=80=8B
your system

<= div>
= =E2=80=8BIs it likely we could build a multi-platform primitive =E2=80=8Bth= at would supply that information given what you have said?
=E2=80=8B=E2= =80=8B=E2=80=8B
=E2= =80=8B=E2=80=8B
and (2) a function would be needed to get the attribut= es of
=E2=80=8B=E2=80=8B
those windows.

= =E2=80=8B2 seems straightforward.

Bob
=E2=80=8B=E2=80=8B
--001a114d6da08149f4055b84f226-- From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 14 14:48:20 2017 Received: (at 28620) by debbugs.gnu.org; 14 Oct 2017 18:48:20 +0000 Received: from localhost ([127.0.0.1]:40509 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3RTw-0000cK-0m for submit@debbugs.gnu.org; Sat, 14 Oct 2017 14:48:20 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41708) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3RTu-0000c1-1U for 28620@debbugs.gnu.org; Sat, 14 Oct 2017 14:48:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e3RTl-00067x-Eh for 28620@debbugs.gnu.org; Sat, 14 Oct 2017 14:48:12 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE, RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48710) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e3RTl-00067V-BR for 28620@debbugs.gnu.org; Sat, 14 Oct 2017 14:48:09 -0400 Received: from mail-qk0-f177.google.com ([209.85.220.177]:49919) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1e3RTl-0000oX-16 for 28620@debbugs.gnu.org; Sat, 14 Oct 2017 14:48:09 -0400 Received: by mail-qk0-f177.google.com with SMTP id q83so5484540qke.6 for <28620@debbugs.gnu.org>; Sat, 14 Oct 2017 11:48:08 -0700 (PDT) X-Gm-Message-State: AMCzsaUl6CtJZalzmpg3s9q23L/kAEpzUiAQrxy2pZwVxq0lm23Dfbfy jFVvrNCQn7wpsT+rA8qYM54lfKruvPS6skCoKxY= X-Google-Smtp-Source: AOwi7QBbTvpc29+y6ffpNZEo82mbM+j5wJx0bOGKpagCaTZ16JeNX9OkDR6ews8+UthA+PnVqDfH7iBT1Qrm7klzaSU= X-Received: by 10.55.12.130 with SMTP id 124mr7395300qkm.186.1508006888463; Sat, 14 Oct 2017 11:48:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.34.225 with HTTP; Sat, 14 Oct 2017 11:47:37 -0700 (PDT) In-Reply-To: References: <83wp4e3nvx.fsf@gnu.org> <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <83vajwytja.fsf@gnu.org> <83poa4yqyq.fsf@gnu.org> <83376qouoj.fsf@gnu.org> <59DF2260.5030204@gmx.at> <59E1CC55.2090400@gmx.at> From: Robert Weiner Date: Sat, 14 Oct 2017 14:47:37 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records wrong release window To: martin rudalics Content-Type: multipart/alternative; boundary="001a114d6da0e7e13f055b863632" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 28620 Cc: Eli Zaretskii , Alan Third , 28620@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rswgnu@gmail.com Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.5 (----) --001a114d6da0e7e13f055b863632 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Oct 14, 2017 at 1:16 PM, Robert Weiner wrote: > it still leaves the issue of recognizing whether a drag release event map= s > to an Emacs frame or not (when the frame is covered by an external app's > window). I already have code that recognizes this in Lisp; we should mak= e > it a primitive so the drag release code in Emacs could report more useful > and accurate information in drag release events. > =E2=80=8BI misspoke. I have code that detects when the release falls outsi= de of the bounds of any Emacs frame. However, when the release event is over an Emacs frame that is covered by another application's window, we don't yet have any information to tell us that, so I cannot detect it yet. That is the problem we are discussing how to solve in a general way. Bob =E2=80=8B --001a114d6da0e7e13f055b863632 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Oct 14, 2= 017 at 1:16 PM, Robert Weiner <rsw= @gnu.org> wrote:=
it still leaves the issue of recognizing whether a drag rel= ease event maps to an Emacs frame or not (when the frame is covered by an e= xternal app's window).=C2=A0 I already have code that recognizes this i= n Lisp; we should make it a primitive so the drag release code in Emacs cou= ld report more useful and accurate information in drag release events.
<= /div>

=E2=80=8BI misspoke.=C2=A0 I have code= that detects when the release falls outside of the bounds of any Emacs fra= me.=C2=A0 However, when the release event is over an Emacs frame that is co= vered by another application's window, we don't yet have any inform= ation to tell us that, so I cannot detect it yet.=C2=A0 That is the problem= we are discussing how to solve in a general way.

Bob
=E2=80=8B
--001a114d6da0e7e13f055b863632-- From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 14 23:32:14 2017 Received: (at 28620) by debbugs.gnu.org; 15 Oct 2017 03:32:14 +0000 Received: from localhost ([127.0.0.1]:40831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3Zew-0002Ut-GK for submit@debbugs.gnu.org; Sat, 14 Oct 2017 23:32:14 -0400 Received: from eggs.gnu.org ([208.118.235.92]:60388) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3Zev-0002Uf-4H for 28620@debbugs.gnu.org; Sat, 14 Oct 2017 23:32:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e3Zek-0002jz-SS for 28620@debbugs.gnu.org; Sat, 14 Oct 2017 23:32:07 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE, RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60873) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e3Zek-0002jk-Pc for 28620@debbugs.gnu.org; Sat, 14 Oct 2017 23:32:02 -0400 Received: from mail-qk0-f170.google.com ([209.85.220.170]:44185) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1e3Zek-0002ym-Cj for 28620@debbugs.gnu.org; Sat, 14 Oct 2017 23:32:02 -0400 Received: by mail-qk0-f170.google.com with SMTP id r64so9215122qkc.1 for <28620@debbugs.gnu.org>; Sat, 14 Oct 2017 20:32:02 -0700 (PDT) X-Gm-Message-State: AMCzsaXHm2PyTpKw48rOQkWKgbU+wA2SHUGAN3ozcGKwioGyOTnvhpcv nlVR8nkzyEDXRV5Chi2E1amebvT8i3HrFRhWJqY= X-Google-Smtp-Source: ABhQp+Q6l32MDdFLmSfK59VsADSR7VqDFt9csogjA8XeYRioYcjuHBzDLwpG1BgRLzPIQ+tJZamxWAIY3EdOGu1QalA= X-Received: by 10.55.124.198 with SMTP id x189mr8664833qkc.40.1508038321909; Sat, 14 Oct 2017 20:32:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.34.225 with HTTP; Sat, 14 Oct 2017 20:31:31 -0700 (PDT) In-Reply-To: References: <83wp4e3nvx.fsf@gnu.org> <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <83vajwytja.fsf@gnu.org> <83poa4yqyq.fsf@gnu.org> <83376qouoj.fsf@gnu.org> <59DF2260.5030204@gmx.at> <59E1CC55.2090400@gmx.at> From: Robert Weiner Date: Sat, 14 Oct 2017 23:31:31 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records wrong release window To: martin rudalics Content-Type: multipart/alternative; boundary="94eb2c0626227c3719055b8d88ca" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 28620 Cc: Eli Zaretskii , Alan Third , 28620@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rswgnu@gmail.com Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.5 (----) --94eb2c0626227c3719055b8d88ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Oct 14, 2017 at 2:47 PM, Robert Weiner wrote: > On Sat, Oct 14, 2017 at 1:16 PM, Robert Weiner wrote: > >> it still leaves the issue of recognizing whether a drag release event >> maps to an Emacs frame or not (when the frame is covered by an external >> app's window). >> > =E2=80=8BI have written a Python script that can be used to get this answer= . (It uses the Python-to-Objective-C bridge library that exposes the relevant Mac APIs to Python)=E2=80=8B. The script takes two arguments, X and Y screen = pixel coordinates, gets a list of all visible application windows in Z-order and then prints the application name of the first window that intersects the (X,Y) position, if any. If that window is an Emacs frame, we have a match and otherwise, we don't. This is a short script that really needs to be recoded into an Objective-C function that can be exposed to Emacs Lisp. If anyone who is familiar with macOS Objective-C code would want to work with me on this, email me and I'll provide the Python code. It is only about 28 lines. -- Bob --94eb2c0626227c3719055b8d88ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Oct 14, 2= 017 at 2:47 PM, Robert Weiner <rsw= @gnu.org> wrote:=
On Sat, Oct 14, 2017 at 1:16 PM, Robert Weiner <rsw@gnu.org> wrote:
it still leaves= the issue of recognizing whether a drag release event maps to an Emacs fra= me or not (when the frame is covered by an external app's window).

=E2=80= =8BI have written a Python script that can be used to get this answer.=C2= =A0 (It uses the Python-to-Objective-C bridge library that exposes the rele= vant Mac APIs to Python)=E2=80=8B.=C2=A0 The script=C2=A0 takes two argumen= ts, X and Y screen pixel coordinates, gets a list of all visible applicatio= n windows in Z-order and then prints the application name of the first wind= ow that intersects the (X,Y) position, if any.=C2=A0 If that window is an E= macs frame, we have a match and otherwise, we don't.

This is a s= hort script that really needs to be recoded into an Objective-C function th= at can be exposed to Emacs Lisp.=C2=A0 If anyone who is familiar with macOS= Objective-C code would want to work with me on this, email me and I'll= provide the Python code.=C2=A0 It is only about 28 lines.=C2=A0 -- Bob


--94eb2c0626227c3719055b8d88ca-- From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 15 05:40:34 2017 Received: (at 28620) by debbugs.gnu.org; 15 Oct 2017 09:40:34 +0000 Received: from localhost ([127.0.0.1]:40953 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3fPO-0005Ls-3A for submit@debbugs.gnu.org; Sun, 15 Oct 2017 05:40:34 -0400 Received: from mout.gmx.net ([212.227.17.21]:59063) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3fPM-0005Lc-DT for 28620@debbugs.gnu.org; Sun, 15 Oct 2017 05:40:32 -0400 Received: from [192.168.1.100] ([46.125.250.23]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Mc9U3-1dmPV201Tz-00JYNJ; Sun, 15 Oct 2017 11:40:15 +0200 Message-ID: <59E32CFA.5080405@gmx.at> Date: Sun, 15 Oct 2017 11:40:10 +0200 From: martin rudalics MIME-Version: 1.0 To: rswgnu@gmail.com Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records wrong release window References: <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <83vajwytja.fsf@gnu.org> <83poa4yqyq.fsf@gnu.org> <83376qouoj.fsf@gnu.org> <59DF2260.5030204@gmx.at> <59E1CC55.2090400@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:vGSCNXEr076weuVQ0zJ86pjQVruB39e8tO3HEk0QXCMbM5hSb2G 5U+crDvWY5zydQJZjvHVu5b18NhIDZEvdKZoNSbR62o4TrNLgivSY41sQEgn6rLBRI+/ZNK pyX/pilycgG/YrPcvHHjekRhQl6zTkm5PNwU2xczmoFyBWxyhtcgh7L85+RUa0LWO8MbDrD S04BButiIDjjh5J0hp3CA== X-UI-Out-Filterresults: notjunk:1;V01:K0:5QbZCc0juLQ=:SN1jc99XkNIQQf+FLB+zMS xsIoJYovJ/aniRyrbhvYgsWBHbJVsTxQSIv3dWsV3BYFXpBWP4zvWTxjjHegcQ3MvYe/r7ZpN MIkbRiCPZCzoMqy3Ga3qZoBJxhSTGXbjTsNzBuzEgyfhD5OikmcYdnobnTBMPszMQQkLWB/GU nAy6xn/YwN5W0rlF9bAQXhrJEFU+O1a4PNJpPJr0BZH1yvVeAE39qaAcLPebDfdFsnb1rBqua lQNKLs/GqmVxSwmg5beKDC64Yh3/W1Ieui2sLXLWg0QIY4xx4Dd4oYPHO+3PbonrqEYwvc3gb 83lZLjCUpF3mVaSE/8hVsZ9lArlBCrgjiIqrOJuw7VNu1Fio6E9w/PEpiDwL0/otEMAi7W5Rk 1knsYZUS0O6tmX4CNZUKbu/QFWzDf31Y+Xvx/dQ+IS+M4rBTeV+ZqBFRF8P467dcXcmFM6hiY JF0w6vSdC6MqpuqliWy5M0OXXNQyIvSr9tPtKyUX73BoThtuLxbUZI2DIdgRD4Vt7HPApfopl BMSW/jnLyJFErYMoCjR3H+lhakd9RWLmZMS+3Xs9gE/B+Bu4oYWfz+GVs86RO04tmpN51615w AuVCBju+hP+ioM7qA53XC/6/7EFZgE5oTGiCE9Jo0bOi8TQtEScgXFHeUZApcPjq8Rtwj4WTl ITfHy41hQvSpUiG0tqE2UU7dx1wc+IOGjRUlBWJHKYfzS27XTX63AAGpONc4ZyLVKXeXKZ56n vU5BL8Bs28CTqK4wxVPEeBWSAuQU2Y9+qKPKIJYK70gXoGrNaHISsEROCCjOTy2PuBf0nv+Ov xQMT/WC9cGjbuAD2uiL1PhkxvKdIm3vMpjgLWZ8fQHfZLcyRWqOhBk/n86/unvh2SfG3KS2 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 28620 Cc: Eli Zaretskii , Alan Third , 28620@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > =E2=80=8BOk, that indicates that drag-and-drop from Emacs to external = applications > is unlikely but it still leaves the issue of recognizing whether a dra= g > release event maps to an Emacs frame or not (when the frame is covered= by > an external app's window). I already have code that recognizes this i= n > Lisp; we should make it a primitive so the drag release code in Emacs = could > report more useful and accurate information in drag release events. Even if the Emacs frame is covered by another application's frame, nothing prevents us from having that covered Emacs frame accept the drop. We could even give frames a "no-accept-drops" parameter and this way have a drop on such frames pass the drop through to yet another frame below that does accept drops. > I guess you are saying that Emacs drag events must start and end withi= n > Emacs frames. I think about it a bit differently. Since the mouse ca= n > move in and out of Emacs frames and release events can occur (in logic= al > Z-ordered OS window space) outside of Emacs, yet still register with E= macs > (when the release occurs within the geometry of a frame but the frame = is > covered by another app's window), I think Emacs event handling should > return different information when the release frame is not the topmost= > OS-level window at the point of release. Then handler code could disp= atch > as necessary. But to be useful, that "handler code" must be written and such code must follow a standard interface for the OS used. Consider the trivial task that one Emacs instance wants to drop some text to a second Emacs instance. How would we trigger the drop event on that second instance? > =E2=80=8BEach window has a 'visible' attribute. Are you saying this i= s not > accurate these days?=E2=80=8B Yes. The GTK manual says that Modern composited windowing systems with pervasive transparency make it impossible to track the visibility of a window reliably, >> (1) =E2=80=98frame-list-z-order=E2=80=99 would have to be able to ret= urn all windows on >> =E2=80=8B=E2=80=8B >> your system > > > =E2=80=8BIs it likely we could build a multi-platform primitive =E2=80= =8Bthat would supply > that information given what you have said? At least for top-level windows. This will work as long a child windows are fully contained by their parents which IIUC is not necessarily true for macOS systems. >> and (2) a function would be needed to get the attributes of >> =E2=80=8B=E2=80=8B >> those windows. > > > =E2=80=8B2 seems straightforward. How accurate these attributes will be depends on the windowing system used. Look at how hard frame_geometry occasionally works to just get the real screen estate of an Emacs frame. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 16 11:11:43 2017 Received: (at 28620) by debbugs.gnu.org; 16 Oct 2017 15:11:43 +0000 Received: from localhost ([127.0.0.1]:43989 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e473P-0001as-Jx for submit@debbugs.gnu.org; Mon, 16 Oct 2017 11:11:43 -0400 Received: from mail-qt0-f172.google.com ([209.85.216.172]:47193) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e473M-0001ae-E3 for 28620@debbugs.gnu.org; Mon, 16 Oct 2017 11:11:40 -0400 Received: by mail-qt0-f172.google.com with SMTP id z50so32308764qtj.4 for <28620@debbugs.gnu.org>; Mon, 16 Oct 2017 08:11:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=HUINbFV68No7mC/PAbj57IgLV+6RmE3AoY6ZudIllDI=; b=WDOM+OUiVIdwK4TBHJnSywdfubKLgVd0GAsVS88vnuN2Yw0gI9qUkKAwFH7sC2fSzc e0knEut9K7JvUm6JLFwXpqVDh6UUctdBqq/gHBZTJOUQrXMtXSFvstefSOrEME5FPch+ a/jnLjgOEk0ykWPu4xeyI4ylv9Of0uDb8bUdCNGfMW8Ky9GKZOHCDYeSAUFx9M/3TtbP GqFnwrv+pzWaIjANeQmH8UvDNvZ3fV5BztcwU8VSqWMo4C12YsNvKy3ktXe/USh2/QGC M0Rh+6BqrgsaOadUnR9VhSqrk1CRiUFE/6PHS3e37nTJTXbVhIi+aaG1h0/IEqu12cfB lakw== X-Gm-Message-State: AMCzsaVirZQeMMWmyRT2Uz/oW5Q7Pl8mXmDlKjDHausOOzKRtF1YlxPY qpRHt5s1nik9T9XM+98vwbtXbw== X-Google-Smtp-Source: AOwi7QALM4VwWoSBF07bQrzJ6JkWg6vwzMR+eo3fYSPlgjmmVlGCOZc4m3RPpHW7NEbHeDl1Gu4v/A== X-Received: by 10.200.45.28 with SMTP id n28mr15192692qta.100.1508166694952; Mon, 16 Oct 2017 08:11:34 -0700 (PDT) Received: from bka-iMac.local.gnu.org (ool-2f1481cf.dyn.optonline.net. [47.20.129.207]) by smtp.gmail.com with ESMTPSA id t34sm4978670qtb.79.2017.10.16.08.11.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 16 Oct 2017 08:11:34 -0700 (PDT) From: Bob Weiner To: martin rudalics , Eli Zaretskii , 28620@debbugs.gnu.org Subject: Re: Emacs bug#28620: (PARTIAL SOLUTION) mouse-position wrong on macOS and Windows 7 after mouse-1 click Date: Mon, 16 Oct 2017 11:11:33 -0400 In-Reply-To: (Robert Weiner's message of "Sat, 30 Sep 2017 17:56:47 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) 27.0.50, InfoDock 4.0.8 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 28620 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) Robert Weiner writes: I wrote: > > =E2=80=8BThe issue, to recap, is that I can't find a function that > will report the window that a mouse release button event > occurs in if the depress and release are in different frames > (for Emacs 25). > > In fact, the release event (drag event) contains the wrong > frame (that of the depress rather than the release). The wrong=20 > frame is also reported by mouse-position and mouse-pixel-position, > so window-at can't be used either. The following is a temporary fix for the mouse-position and mouse-pixel-position part of the problem. Something needs to be fixed in the original functions in the C code, though. -- Bob ;; From mouse-position: ;; f =3D SELECTED_FRAME (); ;; XSETFRAME (lispy_dummy, f); ;; It seems like the XSETFRAME macro is not properly copying the value of = f on initial frame selection under the macOS window system. ;; The problem occurs on other systems as well, e.g. Emacs 25.2 under Wind= ows 7. ;; The function below is a temporary fix for this. (setq mouse-position-function (lambda (frame-x-dot-y) "Under macOS, mouse-position and mouse-pixel-position sometimes fail to re= turn the selected-frame (returning the prior frame instead); fix that here." (setcar frame-x-dot-y (selected-frame)) frame-x-dot-y)) From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 16 11:57:43 2017 Received: (at 28620) by debbugs.gnu.org; 16 Oct 2017 15:57:43 +0000 Received: from localhost ([127.0.0.1]:44059 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e47lv-0002j1-1m for submit@debbugs.gnu.org; Mon, 16 Oct 2017 11:57:43 -0400 Received: from mail-qt0-f176.google.com ([209.85.216.176]:53166) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e47lt-0002ip-AJ for 28620@debbugs.gnu.org; Mon, 16 Oct 2017 11:57:41 -0400 Received: by mail-qt0-f176.google.com with SMTP id 31so7178556qtz.9 for <28620@debbugs.gnu.org>; Mon, 16 Oct 2017 08:57:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=MAdhaXoNXFw2STn2lSTH3qChzrbSHKaBAukUpqCrr5o=; b=tb7vO7qO6qwrUaKC/I6aH1ZPBLZdakQB6ncZl8vmi9O9hg6xSA296zX83ml9G7K7W2 1Vnc6RAiJe6NIvPZ5hiyYKZvoRjdvBrWwEAeMNOPrAQLNoHzscm6xUjf1mHvrf9WZAQl dcMzvXDQQpjmDUT73SmqBUTKsfoTn4i3Uj8jR7YbaYQGmuFNyf2t7Xq/KxiSvf2doIbM U2UmcJI25WMUTlbo3FFnwLGfrGfkGhdOTSxqcPxPmL/ajCFo7ui3ffa8Gr3yQkSkGHa4 kXAj77ehCfpxskHHwjeIUxtbvIhSFdHIJLhV687lqOZ0aXHoAiD+oZMyouB41xj/k2w6 1qyg== X-Gm-Message-State: AMCzsaUWgg0JSD0JnjdmKSUceyZ8txTuiOumPbSYEBuZIPxE7tJ2nwGz H5xsSfLhzvZhUwbapUlJ6S4= X-Google-Smtp-Source: ABhQp+TBGvWmWmTTOdtvVfBbUN6QvgqAmgDlXZp68GrGiUeVHa12CY/3wTR7NfNLMtvaGGtdu1VQJQ== X-Received: by 10.200.8.53 with SMTP id u50mr14348709qth.106.1508169455612; Mon, 16 Oct 2017 08:57:35 -0700 (PDT) Received: from bka-iMac.local.gnu.org (ool-2f1481cf.dyn.optonline.net. [47.20.129.207]) by smtp.gmail.com with ESMTPSA id p64sm4698787qkd.67.2017.10.16.08.57.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 16 Oct 2017 08:57:34 -0700 (PDT) From: Bob Weiner To: 28620@debbugs.gnu.org Subject: Re: bug#28620: (PARTIAL SOLUTION) Mouse drag event records wrong window for release when crossing frames References: Date: Mon, 16 Oct 2017 11:57:33 -0400 In-Reply-To: (Robert Weiner's message of "Wed, 27 Sep 2017 11:44:06 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) 27.0.50, InfoDock 4.0.8 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 28620 Cc: martin rudalics , Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) Robert Weiner writes: > With Emacs 25.3 under MacOS 10.12, a drag with mouse-1 depressed from > the text area of frame F1 to the text area of frame F2 improperly > generates a drag event whose (posn-window (event-end )) shows > F1 rather than F2. > > Note that for a drag between frames, posn-window should return a frame > (according to the Elisp manual but not its own doc string). The bug is > that the event itself records the wrong frame (the depress frame rather > than the release frame). > > I have confirmed this with Emacs 25.2 under Windows 7 as well. I have this fixed and working nicely for the GNU Hyperbole package, which does extensive mouse drag handling. Hyperbole can now drag buffer menu items, dired items, and buffers themselves across frames and display them in any window that receives a release event. It can also tell whether the topmost application window at the point of release was an Emacs frame or a window of another application (for macOS windowing only), so drags can start in Emacs and end outside. But this required a good bit of code that I include below just so you can see what was required. It would be much simpler once the drag event release C code in Emacs is improved based upon this work to at least return the actual window of drag release. Bob ---------- Code from forthcoming Hyperbole 6.0.2e pre-release (the Python script at the end will be converted to Objective-C at some point): (defvar action-key-depress-args nil "List of mouse event args from most recent depress of the Action Key.") (defvar assist-key-depress-args nil "List of mouse event args from most recent depress of the Assist Key.") (defvar action-key-release-args nil "List of mouse event args from most recent release of the Action Key.") (defvar assist-key-release-args nil "List of mouse event args from most recent release of the Assist Key.") (defvar action-key-depress-window nil "The last window in which the Action Key was depressed or nil. This is set to nil when the depress is on an inactive minibuffer.") (defvar assist-key-depress-window nil "The last window in which the Assist Key was depressed or nil. This is set to nil when the depress is on an inactive minibuffer.") (defvar action-key-release-window nil "The last window in which the Action Key was released or nil.") (defvar assist-key-release-window nil "The last window in which the Assist Key was released or nil.") (defvar action-key-depress-position nil "The last screen position at which the Action Key was depressed or nil.") (defvar assist-key-depress-position nil "The last screen position at which the Assist Key was depressed or nil.") (defun hmouse-key-release-args-emacs (event) "For GNU Emacs, return a possibly modified version of EVENT as a list. For mouse drags and double and triple clicks, remove any depress location, compute the actual release location and include that." (if (integerp event) (list event) (let ((ev-type-str (and (listp event) (symbol-name (car event))))) (if (or (and ev-type-str (string-match "\\(double\\|triple\\)-mouse" ev-type-str)) (not (= (length event) 3))) event (let ((pos (event-end event)) coords window-and-char-coords) (when (and ev-type-str (string-match "drag-mouse" ev-type-str) ;; end of drag event; If drag crossed frames, the location ;; will contain the frame of the depress point and ;; some relative coordinates; change these to the window of ;; release and window's character coordinates if within a window ;; and to nil if outside of Emacs (as best we can tell). (framep (posn-window pos))) (setq window-and-char-coords (hmouse-window-coordinates event) window (car window-and-char-coords) coords (cadr window-and-char-coords)) ;; Modify the values in the event-end structure even if no ;; valid window was found. (setcar pos window) (setcar (nthcdr 2 pos) coords))) ;; Remove depress coordinates and send only original release coordinates. (list (car event) (nth 2 event)))))) (defun hmouse-window-coordinates (&optional event) "Return a list (window (x-chars . y-chars)) for optional EVENT. Always ignores EVENT coordinates and uses current mouse position. The area of the EVENT is utilized. If EVENT is not given and the free variable `assist-flag' is non-nil, EVENT is set to `assist-key-release-args', otherwise, `action-key-release-args'. The coordinates x-chars and y-chars are relative character coordinates within the window. If POSITION is not in a live window, return nil. Considers all windows on the selected frame's display." (interactive) (unless (eventp event) (setq event (if assist-flag assist-key-release-args action-key-release-args))) (let* ((position (mouse-absolute-pixel-position)) (pos-x (car position)) (pos-y (cdr position)) (window (hmouse-window-at-absolute-pixel-position position t)) (edges (when (window-live-p window) (window-edges window t t t))) left top right bottom frame) (when edges (setq left (nth 0 edges) top (nth 1 edges) right (nth 2 edges) bottom (nth 3 edges)) (when (or (and event (eq (posn-area (event-start event)) 'mode-line)) (and (>= pos-x left) (<= pos-x right) (>= pos-y top) (<= pos-y bottom))) ;; If position is in a live window, compute position's character ;; coordinates within the window and return the window with these ;; coordinates. (setq frame (window-frame window) pos-x (round (/ (- pos-x left) (frame-char-width frame))) pos-y (round (/ (- pos-y top) (+ (frame-char-height frame) (hmouse-vertical-line-spacing frame))))))) (when (called-interactively-p 'interactive) (message "%s at %s coordinates (%s . %s)" (if edges window "No live Emacs window") (if frame "character" "absolute pixel") pos-x pos-y)) (when edges (list window (cons pos-x pos-y))))) (defvar hmouse-verify-release-window-flag t "When non-nil under the macOS window system, verifies the application of top-most window. Forces a window system check at a screen position that the top-most window there is an Emacs frame or treats the location as outside Emacs, even though an Emacs frame may be below the top-most window. See function `hmouse-window-at-absolute-pixel-position' for more details.") (defun hmouse-window-at-absolute-pixel-position (&optional position release-flag) "Return the top-most Emacs window at optional POSITION ((x . y) in absolute pixels) or mouse position. If POSITION is not in a window, return nil. Considers all windows on the same display as the selected frame. If optional RELEASE-FLAG is non-nil, this is part of a Smart Key release computation, so optimize window selection based on the depress window already computed. If the selected frame is a graphical macOS window and `hmouse-verity-release-window-flag' is non-nil, then return the top-most Emacs window only if it is the top-most application window at the position (not below another application's window)." (interactive) (setq position (or position (mouse-absolute-pixel-position))) ;; Proper top-to-bottom listing of frames is available only in Emacs ;; 26 and above. For prior versions, the ordering of the frames ;; returned is not guaranteed, so the frame whose window is returned ;; may not be the uppermost. (let* ((top-to-bottom-frames (if (fboundp 'frame-list-z-order) (frame-list-z-order) (frame-list))) (pos-x (car position)) (pos-y (cdr position)) edges left top right bottom frame in-frame window) ;; First find top-most frame containing position. (while (and (not in-frame) top-to-bottom-frames) (setq frame (car top-to-bottom-frames) top-to-bottom-frames (cdr top-to-bottom-frames)) ;; Check that in-frame is valid with frame-live-p since under macOS ;; when position is outside a frame, in-frame could be invalid and ;; frame-visible-p would trigger an error in that case. (when (and (frame-live-p frame) (frame-visible-p frame)) (setq edges (frame-edges frame) left (nth 0 edges) top (nth 1 edges) right (nth 2 edges) bottom (nth 3 edges)) (when (and (>= pos-x left) (<= pos-x right) (>= pos-y top) (<= pos-y bottom)) (setq in-frame frame)))) ;; If in-frame is found, find which of its windows contains ;; position and return that. The window-at call below requires ;; character coordinates relative to in-frame, so compute them. (when in-frame (let ((depress-position (and release-flag (if assist-flag assist-key-depress-position action-key-depress-position))) (depress-window (and release-flag (if assist-flag assist-key-depress-window action-key-depress-window)))) (if (and release-flag depress-window (equal position depress-position)) ;; This was a click, so we know that the frame of the click ;; is topmost on screen or the mouse events would not have ;; been routed to Emacs. Reuse saved window of depress rather ;; then running possibly expensive computation to find the ;; topmost application window. (setq window depress-window) (let ((char-x (/ (- pos-x left) (frame-char-width in-frame))) (line-y (/ (- pos-y top) (+ (frame-char-height in-frame) (hmouse-vertical-line-spacing in-frame))))) (setq window (window-at char-x line-y in-frame))) ;; ;; Even if in-frame is found, under click-to-focus external window ;; managers, Emacs may have received the drag release event when ;; in-frame was covered by an external application's window. ;; Emacs presently has no way to handle this. However, for the ;; macOS window system only, Hyperbole has a Python script, topwin, which ;; computes the application of the topmost window at the point of release. ;; If that is Emacs, then we have the right window and nothing need be ;; done; otherwise, set window to nil and return. ;; (when (and hmouse-verify-release-window-flag window (eq (window-system) 'ns)) (let ((topwin (executable-find "topwin")) (case-fold-search t) topmost-app) (when (and topwin (file-executable-p topwin)) (setq topmost-app (shell-command-to-string (format "topwin %d %d" pos-x pos-y))) (cond ((string-match "emacs" topmost-app)) ; In an Emacs frame, do nothing. ((or (equal topmost-app "") ;; Any non-Emacs app window (string-match "\\`\\[" topmost-app)) ;; Outside of any Emacs frame (setq window nil)) (t ; topwin error message ;; Setup of the topwin script is somewhat complicated, ;; so don't trigger an error just because of it. But ;; display a message so the user knows something happened ;; when topwin encounters an error. (message "(Hyperbole): topwin Python script error: %s" topmost-app))))))))) (when (called-interactively-p 'interactive) (message "%s at absolute pixel position %s" (or window "No Emacs window") position)) window)) ;; Based on code from subr.el. (defun hmouse-vertical-line-spacing (frame) "Return any extra vertical spacing in pixels between text lines or 0 if none." (let ((spacing (when (display-graphic-p frame) (or (with-current-buffer (window-buffer (frame-selected-window frame)) line-spacing) (frame-parameter frame 'line-spacing))))) (cond ((floatp spacing) (setq spacing (truncate (* spacing (frame-char-height frame))))) ((null spacing) (setq spacing 0))) spacing)) ------ #!python2 # # SUMMARY: topwin: Outputs the [application name] of the topmost window at mouse screen position or nothing if none # USAGE: