bug#19988: 25.0.50; Drag events ending in different frame

bug#19988: 25.0.50; Drag events ending in different frame

[Tassilo Horn]

The info docs describe the components of drag-events as

,----[ (info "(elisp)Drag Events") ]
| (EVENT-TYPE
|       (WINDOW1 START-POSITION)
|       (WINDOW2 END-POSITION))
`----

where WINDOW1 is the window where the drag started and WINDOW2 is the
window where the drag ended.

However, that's not correct in case the drag starts in one emacs frame
and ends in another emacs frame.  In those cases, WINDOW2 is the frame
containing WINDOW1.

Is there a reason why drag events cannot work across different frames of
the very same Emacs instance?

Background: I've written a command that uses drag events to swap buffers
of two Emacs windows:

--8<---------------cut here---------------start------------->8---
(defun th/swap-window-buffers-by-dnd (drag-event)
  "Swaps the buffers displayed in the DRAG-EVENT's start and end
window."
  (interactive "e")
  (let ((start-win (cl-caadr drag-event))
	(end-win   (cl-caaddr drag-event)))
    (when (and (windowp start-win)
	       (windowp end-win)
	       (not (eq start-win end-win)))
      (let ((bs (window-buffer start-win))
	    (be (window-buffer end-win)))
	(set-window-buffer start-win be)
	(set-window-buffer end-win bs)))))

(global-set-key (kbd "<C-S-drag-mouse-1>")
		#'th/swap-window-buffers-by-dnd)
--8<---------------cut here---------------end--------------->8---

Right now, it only works for swapping the buffers of two windows in the
same frame but it would be nice if it also allowed to swap the buffers
of two windows in two different frames.



In GNU Emacs 25.0.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.9)
 of 2015-03-03 on thinkpad-t440p
Repository revision: 2cc23f170f920cbfc9df4c28bce6ca9d82c4e6cd
Windowing system distributor `The X.Org Foundation', version 11.0.11701000
System Description:	Arch Linux

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB

Important settings:
  value of $LC_MONETARY: de_DE.utf8
  value of $LC_NUMERIC: de_DE.utf8
  value of $LC_TIME: de_DE.utf8
  value of $LANG: en_US.utf8
  locale-coding-system: utf-8-unix

Major mode: Emacs-Lisp

Minor modes in effect:
  rcirc-track-minor-mode: t
  magit-auto-revert-mode: t
  TeX-PDF-mode: t
  TeX-source-correlate-mode: t
  diff-auto-refine-mode: t
  highlight-parentheses-mode: t
  global-company-mode: t
  company-mode: t
  paredit-mode: t
  global-aggressive-indent-mode: t
  aggressive-indent-mode: t
  highlight-symbol-mode: t
  global-edit-server-edit-mode: t
  recentf-mode: t
  shell-dirtrack-mode: t
  outline-minor-mode: t
  helm-match-plugin-mode: t
  helm-occur-match-plugin-mode: t
  helm-autoresize-mode: t
  global-subword-mode: t
  subword-mode: t
  savehist-mode: t
  show-paren-mode: t
  icomplete-mode: t
  minibuffer-depth-indicate-mode: t
  electric-pair-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-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

Recent messages:
Mark set
next-line: End of buffer
Mark set [2 times]
next-line: End of buffer
Auto-saving...
Mark set
Using try-expand-dabbrev
th/swap-window-buffers-by-dnd
S: #<window 244 on *info*>, E: #<frame *info* (Emacs) 0x9dfa078> [2 times]
S: #<window 207 on dot-emacs.el>, E: #<window 207 on dot-emacs.el>

Load-path shadows:
~/Repos/el/auctex/lpath hides ~/Repos/el/gnus/lisp/lpath
~/Repos/el/gnus/lisp/md4 hides /home/horn/Repos/el/emacs/lisp/md4
~/Repos/el/gnus/lisp/color hides /home/horn/Repos/el/emacs/lisp/color
~/Repos/el/gnus/lisp/format-spec hides /home/horn/Repos/el/emacs/lisp/format-spec
~/Repos/el/gnus/lisp/password-cache hides /home/horn/Repos/el/emacs/lisp/password-cache
~/Repos/el/gnus/lisp/hex-util hides /home/horn/Repos/el/emacs/lisp/hex-util
~/Repos/el/gnus/lisp/dns-mode hides /home/horn/Repos/el/emacs/lisp/textmodes/dns-mode
/home/horn/.emacs.d/elpa/org-20150302/ob-plantuml hides /home/horn/Repos/el/emacs/lisp/org/ob-plantuml
/home/horn/.emacs.d/elpa/org-20150302/org-archive hides /home/horn/Repos/el/emacs/lisp/org/org-archive
/home/horn/.emacs.d/elpa/org-20150302/org-w3m hides /home/horn/Repos/el/emacs/lisp/org/org-w3m
/home/horn/.emacs.d/elpa/org-20150302/ox-org hides /home/horn/Repos/el/emacs/lisp/org/ox-org
/home/horn/.emacs.d/elpa/org-20150302/ob hides /home/horn/Repos/el/emacs/lisp/org/ob
/home/horn/.emacs.d/elpa/org-20150302/org-faces hides /home/horn/Repos/el/emacs/lisp/org/org-faces
/home/horn/.emacs.d/elpa/org-20150302/ob-awk hides /home/horn/Repos/el/emacs/lisp/org/ob-awk
/home/horn/.emacs.d/elpa/org-20150302/org-habit hides /home/horn/Repos/el/emacs/lisp/org/org-habit
/home/horn/.emacs.d/elpa/org-20150302/ob-sass hides /home/horn/Repos/el/emacs/lisp/org/ob-sass
/home/horn/.emacs.d/elpa/org-20150302/org-ctags hides /home/horn/Repos/el/emacs/lisp/org/org-ctags
/home/horn/.emacs.d/elpa/org-20150302/ob-screen hides /home/horn/Repos/el/emacs/lisp/org/ob-screen
/home/horn/.emacs.d/elpa/org-20150302/ox-md hides /home/horn/Repos/el/emacs/lisp/org/ox-md
/home/horn/.emacs.d/elpa/org-20150302/ox-beamer hides /home/horn/Repos/el/emacs/lisp/org/ox-beamer
/home/horn/.emacs.d/elpa/org-20150302/org-loaddefs hides /home/horn/Repos/el/emacs/lisp/org/org-loaddefs
/home/horn/.emacs.d/elpa/org-20150302/ob-perl hides /home/horn/Repos/el/emacs/lisp/org/ob-perl
/home/horn/.emacs.d/elpa/org-20150302/org-rmail hides /home/horn/Repos/el/emacs/lisp/org/org-rmail
/home/horn/.emacs.d/elpa/org-20150302/org-id hides /home/horn/Repos/el/emacs/lisp/org/org-id
/home/horn/.emacs.d/elpa/org-20150302/ox-publish hides /home/horn/Repos/el/emacs/lisp/org/ox-publish
/home/horn/.emacs.d/elpa/org-20150302/ob-maxima hides /home/horn/Repos/el/emacs/lisp/org/ob-maxima
/home/horn/.emacs.d/elpa/org-20150302/org-install hides /home/horn/Repos/el/emacs/lisp/org/org-install
/home/horn/.emacs.d/elpa/org-20150302/org-feed hides /home/horn/Repos/el/emacs/lisp/org/org-feed
/home/horn/.emacs.d/elpa/org-20150302/ob-R hides /home/horn/Repos/el/emacs/lisp/org/ob-R
/home/horn/.emacs.d/elpa/org-20150302/ox-latex hides /home/horn/Repos/el/emacs/lisp/org/ox-latex
/home/horn/.emacs.d/elpa/org-20150302/org-timer hides /home/horn/Repos/el/emacs/lisp/org/org-timer
/home/horn/.emacs.d/elpa/org-20150302/ob-core hides /home/horn/Repos/el/emacs/lisp/org/ob-core
/home/horn/.emacs.d/elpa/org-20150302/org-datetree hides /home/horn/Repos/el/emacs/lisp/org/org-datetree
/home/horn/.emacs.d/elpa/org-20150302/ob-sql hides /home/horn/Repos/el/emacs/lisp/org/ob-sql
/home/horn/.emacs.d/elpa/org-20150302/ob-js hides /home/horn/Repos/el/emacs/lisp/org/ob-js
/home/horn/.emacs.d/elpa/org-20150302/ob-tangle hides /home/horn/Repos/el/emacs/lisp/org/ob-tangle
/home/horn/.emacs.d/elpa/org-20150302/org-capture hides /home/horn/Repos/el/emacs/lisp/org/org-capture
/home/horn/.emacs.d/elpa/org-20150302/ob-haskell hides /home/horn/Repos/el/emacs/lisp/org/ob-haskell
/home/horn/.emacs.d/elpa/org-20150302/ob-dot hides /home/horn/Repos/el/emacs/lisp/org/ob-dot
/home/horn/.emacs.d/elpa/org-20150302/ob-exp hides /home/horn/Repos/el/emacs/lisp/org/ob-exp
/home/horn/.emacs.d/elpa/org-20150302/org-info hides /home/horn/Repos/el/emacs/lisp/org/org-info
/home/horn/.emacs.d/elpa/org-20150302/ob-octave hides /home/horn/Repos/el/emacs/lisp/org/ob-octave
/home/horn/.emacs.d/elpa/org-20150302/org-mobile hides /home/horn/Repos/el/emacs/lisp/org/org-mobile
/home/horn/.emacs.d/elpa/org-20150302/org-indent hides /home/horn/Repos/el/emacs/lisp/org/org-indent
/home/horn/.emacs.d/elpa/org-20150302/org-attach hides /home/horn/Repos/el/emacs/lisp/org/org-attach
/home/horn/.emacs.d/elpa/org-20150302/ob-java hides /home/horn/Repos/el/emacs/lisp/org/ob-java
/home/horn/.emacs.d/elpa/org-20150302/org-mhe hides /home/horn/Repos/el/emacs/lisp/org/org-mhe
/home/horn/.emacs.d/elpa/org-20150302/ob-scheme hides /home/horn/Repos/el/emacs/lisp/org/ob-scheme
/home/horn/.emacs.d/elpa/org-20150302/ob-lob hides /home/horn/Repos/el/emacs/lisp/org/ob-lob
/home/horn/.emacs.d/elpa/org-20150302/ob-calc hides /home/horn/Repos/el/emacs/lisp/org/ob-calc
/home/horn/.emacs.d/elpa/org-20150302/org-agenda hides /home/horn/Repos/el/emacs/lisp/org/org-agenda
/home/horn/.emacs.d/elpa/org-20150302/org-version hides /home/horn/Repos/el/emacs/lisp/org/org-version
/home/horn/.emacs.d/elpa/org-20150302/org-clock hides /home/horn/Repos/el/emacs/lisp/org/org-clock
/home/horn/.emacs.d/elpa/org-20150302/org-macro hides /home/horn/Repos/el/emacs/lisp/org/org-macro
/home/horn/.emacs.d/elpa/org-20150302/ob-fortran hides /home/horn/Repos/el/emacs/lisp/org/ob-fortran
/home/horn/.emacs.d/elpa/org-20150302/ob-picolisp hides /home/horn/Repos/el/emacs/lisp/org/ob-picolisp
/home/horn/.emacs.d/elpa/org-20150302/ob-mscgen hides /home/horn/Repos/el/emacs/lisp/org/ob-mscgen
/home/horn/.emacs.d/elpa/org-20150302/ox-texinfo hides /home/horn/Repos/el/emacs/lisp/org/ox-texinfo
/home/horn/.emacs.d/elpa/org-20150302/org-table hides /home/horn/Repos/el/emacs/lisp/org/org-table
/home/horn/.emacs.d/elpa/org-20150302/ob-matlab hides /home/horn/Repos/el/emacs/lisp/org/ob-matlab
/home/horn/.emacs.d/elpa/org-20150302/ox-html hides /home/horn/Repos/el/emacs/lisp/org/ox-html
/home/horn/.emacs.d/elpa/org-20150302/ox-icalendar hides /home/horn/Repos/el/emacs/lisp/org/ox-icalendar
/home/horn/.emacs.d/elpa/org-20150302/org-bbdb hides /home/horn/Repos/el/emacs/lisp/org/org-bbdb
/home/horn/.emacs.d/elpa/org-20150302/ob-asymptote hides /home/horn/Repos/el/emacs/lisp/org/ob-asymptote
/home/horn/.emacs.d/elpa/org-20150302/org-eshell hides /home/horn/Repos/el/emacs/lisp/org/org-eshell
/home/horn/.emacs.d/elpa/org-20150302/ob-comint hides /home/horn/Repos/el/emacs/lisp/org/ob-comint
/home/horn/.emacs.d/elpa/org-20150302/org hides /home/horn/Repos/el/emacs/lisp/org/org
/home/horn/.emacs.d/elpa/org-20150302/org-irc hides /home/horn/Repos/el/emacs/lisp/org/org-irc
/home/horn/.emacs.d/elpa/org-20150302/ob-table hides /home/horn/Repos/el/emacs/lisp/org/ob-table
/home/horn/.emacs.d/elpa/org-20150302/ob-scala hides /home/horn/Repos/el/emacs/lisp/org/ob-scala
/home/horn/.emacs.d/elpa/org-20150302/ob-io hides /home/horn/Repos/el/emacs/lisp/org/ob-io
/home/horn/.emacs.d/elpa/org-20150302/ox-ascii hides /home/horn/Repos/el/emacs/lisp/org/ox-ascii
/home/horn/.emacs.d/elpa/org-20150302/ob-lisp hides /home/horn/Repos/el/emacs/lisp/org/ob-lisp
/home/horn/.emacs.d/elpa/org-20150302/org-macs hides /home/horn/Repos/el/emacs/lisp/org/org-macs
/home/horn/.emacs.d/elpa/org-20150302/ob-sqlite hides /home/horn/Repos/el/emacs/lisp/org/ob-sqlite
/home/horn/.emacs.d/elpa/org-20150302/ob-latex hides /home/horn/Repos/el/emacs/lisp/org/ob-latex
/home/horn/.emacs.d/elpa/org-20150302/ob-css hides /home/horn/Repos/el/emacs/lisp/org/ob-css
/home/horn/.emacs.d/elpa/org-20150302/org-protocol hides /home/horn/Repos/el/emacs/lisp/org/org-protocol
/home/horn/.emacs.d/elpa/org-20150302/ob-keys hides /home/horn/Repos/el/emacs/lisp/org/ob-keys
/home/horn/.emacs.d/elpa/org-20150302/org-mouse hides /home/horn/Repos/el/emacs/lisp/org/org-mouse
/home/horn/.emacs.d/elpa/org-20150302/ob-ruby hides /home/horn/Repos/el/emacs/lisp/org/ob-ruby
/home/horn/.emacs.d/elpa/org-20150302/org-element hides /home/horn/Repos/el/emacs/lisp/org/org-element
/home/horn/.emacs.d/elpa/org-20150302/org-bibtex hides /home/horn/Repos/el/emacs/lisp/org/org-bibtex
/home/horn/.emacs.d/elpa/org-20150302/ob-C hides /home/horn/Repos/el/emacs/lisp/org/ob-C
/home/horn/.emacs.d/elpa/org-20150302/org-src hides /home/horn/Repos/el/emacs/lisp/org/org-src
/home/horn/.emacs.d/elpa/org-20150302/ob-makefile hides /home/horn/Repos/el/emacs/lisp/org/ob-makefile
/home/horn/.emacs.d/elpa/org-20150302/org-colview hides /home/horn/Repos/el/emacs/lisp/org/org-colview
/home/horn/.emacs.d/elpa/org-20150302/ob-ledger hides /home/horn/Repos/el/emacs/lisp/org/ob-ledger
/home/horn/.emacs.d/elpa/org-20150302/org-crypt hides /home/horn/Repos/el/emacs/lisp/org/org-crypt
/home/horn/.emacs.d/elpa/org-20150302/ob-shen hides /home/horn/Repos/el/emacs/lisp/org/ob-shen
/home/horn/.emacs.d/elpa/org-20150302/ob-gnuplot hides /home/horn/Repos/el/emacs/lisp/org/ob-gnuplot
/home/horn/.emacs.d/elpa/org-20150302/org-inlinetask hides /home/horn/Repos/el/emacs/lisp/org/org-inlinetask
/home/horn/.emacs.d/elpa/org-20150302/org-gnus hides /home/horn/Repos/el/emacs/lisp/org/org-gnus
/home/horn/.emacs.d/elpa/org-20150302/ob-sh hides /home/horn/Repos/el/emacs/lisp/org/ob-sh
/home/horn/.emacs.d/elpa/org-20150302/org-pcomplete hides /home/horn/Repos/el/emacs/lisp/org/org-pcomplete
/home/horn/.emacs.d/elpa/org-20150302/org-docview hides /home/horn/Repos/el/emacs/lisp/org/org-docview
/home/horn/.emacs.d/elpa/org-20150302/ox-man hides /home/horn/Repos/el/emacs/lisp/org/ox-man
/home/horn/.emacs.d/elpa/org-20150302/org-plot hides /home/horn/Repos/el/emacs/lisp/org/org-plot
/home/horn/.emacs.d/elpa/org-20150302/ox hides /home/horn/Repos/el/emacs/lisp/org/ox
/home/horn/.emacs.d/elpa/org-20150302/ob-python hides /home/horn/Repos/el/emacs/lisp/org/ob-python
/home/horn/.emacs.d/elpa/org-20150302/ob-eval hides /home/horn/Repos/el/emacs/lisp/org/ob-eval
/home/horn/.emacs.d/elpa/org-20150302/ob-clojure hides /home/horn/Repos/el/emacs/lisp/org/ob-clojure
/home/horn/.emacs.d/elpa/org-20150302/ob-ocaml hides /home/horn/Repos/el/emacs/lisp/org/ob-ocaml
/home/horn/.emacs.d/elpa/org-20150302/ox-odt hides /home/horn/Repos/el/emacs/lisp/org/ox-odt
/home/horn/.emacs.d/elpa/org-20150302/org-compat hides /home/horn/Repos/el/emacs/lisp/org/org-compat
/home/horn/.emacs.d/elpa/org-20150302/org-list hides /home/horn/Repos/el/emacs/lisp/org/org-list
/home/horn/.emacs.d/elpa/org-20150302/ob-emacs-lisp hides /home/horn/Repos/el/emacs/lisp/org/ob-emacs-lisp
/home/horn/.emacs.d/elpa/org-20150302/org-entities hides /home/horn/Repos/el/emacs/lisp/org/org-entities
/home/horn/.emacs.d/elpa/org-20150302/ob-ref hides /home/horn/Repos/el/emacs/lisp/org/ob-ref
/home/horn/.emacs.d/elpa/org-20150302/ob-ditaa hides /home/horn/Repos/el/emacs/lisp/org/ob-ditaa
/home/horn/.emacs.d/elpa/org-20150302/ob-lilypond hides /home/horn/Repos/el/emacs/lisp/org/ob-lilypond
/home/horn/.emacs.d/elpa/org-20150302/ob-org hides /home/horn/Repos/el/emacs/lisp/org/ob-org
/home/horn/.emacs.d/elpa/org-20150302/org-footnote hides /home/horn/Repos/el/emacs/lisp/org/org-footnote
~/Repos/el/gnus/lisp/dig hides /home/horn/Repos/el/emacs/lisp/net/dig
~/Repos/el/gnus/lisp/hmac-md5 hides /home/horn/Repos/el/emacs/lisp/net/hmac-md5
~/Repos/el/gnus/lisp/ntlm hides /home/horn/Repos/el/emacs/lisp/net/ntlm
~/Repos/el/gnus/lisp/hmac-def hides /home/horn/Repos/el/emacs/lisp/net/hmac-def
~/Repos/el/gnus/lisp/rfc2104 hides /home/horn/Repos/el/emacs/lisp/net/rfc2104
~/Repos/el/gnus/lisp/sasl-ntlm hides /home/horn/Repos/el/emacs/lisp/net/sasl-ntlm
~/Repos/el/gnus/lisp/sasl-cram hides /home/horn/Repos/el/emacs/lisp/net/sasl-cram
~/Repos/el/gnus/lisp/dns hides /home/horn/Repos/el/emacs/lisp/net/dns
~/Repos/el/gnus/lisp/sasl hides /home/horn/Repos/el/emacs/lisp/net/sasl
~/Repos/el/gnus/lisp/tls hides /home/horn/Repos/el/emacs/lisp/net/tls
~/Repos/el/gnus/lisp/sasl-scram-rfc hides /home/horn/Repos/el/emacs/lisp/net/sasl-scram-rfc
~/Repos/el/gnus/lisp/netrc hides /home/horn/Repos/el/emacs/lisp/net/netrc
~/Repos/el/gnus/lisp/sasl-digest hides /home/horn/Repos/el/emacs/lisp/net/sasl-digest
~/Repos/el/gnus/lisp/uudecode hides /home/horn/Repos/el/emacs/lisp/mail/uudecode
~/Repos/el/gnus/lisp/binhex hides /home/horn/Repos/el/emacs/lisp/mail/binhex
~/Repos/el/gnus/lisp/hashcash hides /home/horn/Repos/el/emacs/lisp/mail/hashcash
~/Repos/el/gnus/lisp/canlock hides /home/horn/Repos/el/emacs/lisp/gnus/canlock
~/Repos/el/gnus/lisp/nneething hides /home/horn/Repos/el/emacs/lisp/gnus/nneething
~/Repos/el/gnus/lisp/mm-encode hides /home/horn/Repos/el/emacs/lisp/gnus/mm-encode
~/Repos/el/gnus/lisp/mm-util hides /home/horn/Repos/el/emacs/lisp/gnus/mm-util
~/Repos/el/gnus/lisp/rfc2047 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2047
~/Repos/el/gnus/lisp/nnml hides /home/horn/Repos/el/emacs/lisp/gnus/nnml
~/Repos/el/gnus/lisp/gnus-cus hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cus
~/Repos/el/gnus/lisp/gnus-range hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-range
~/Repos/el/gnus/lisp/gnus-int hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-int
~/Repos/el/gnus/lisp/gnus-cloud hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cloud
~/Repos/el/gnus/lisp/spam-stat hides /home/horn/Repos/el/emacs/lisp/gnus/spam-stat
~/Repos/el/gnus/lisp/nnmh hides /home/horn/Repos/el/emacs/lisp/gnus/nnmh
~/Repos/el/gnus/lisp/gnus-mlspl hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-mlspl
~/Repos/el/gnus/lisp/deuglify hides /home/horn/Repos/el/emacs/lisp/gnus/deuglify
~/Repos/el/gnus/lisp/gnus-gravatar hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-gravatar
~/Repos/el/gnus/lisp/nngateway hides /home/horn/Repos/el/emacs/lisp/gnus/nngateway
~/Repos/el/gnus/lisp/ietf-drums hides /home/horn/Repos/el/emacs/lisp/gnus/ietf-drums
~/Repos/el/gnus/lisp/mail-parse hides /home/horn/Repos/el/emacs/lisp/gnus/mail-parse
~/Repos/el/gnus/lisp/gnus-salt hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-salt
~/Repos/el/gnus/lisp/nnimap hides /home/horn/Repos/el/emacs/lisp/gnus/nnimap
~/Repos/el/gnus/lisp/gnus-draft hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-draft
~/Repos/el/gnus/lisp/mail-source hides /home/horn/Repos/el/emacs/lisp/gnus/mail-source
~/Repos/el/gnus/lisp/messcompat hides /home/horn/Repos/el/emacs/lisp/gnus/messcompat
~/Repos/el/gnus/lisp/pop3 hides /home/horn/Repos/el/emacs/lisp/gnus/pop3
~/Repos/el/gnus/lisp/nnmaildir hides /home/horn/Repos/el/emacs/lisp/gnus/nnmaildir
~/Repos/el/gnus/lisp/nnheader hides /home/horn/Repos/el/emacs/lisp/gnus/nnheader
~/Repos/el/gnus/lisp/gnus-cite hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cite
~/Repos/el/gnus/lisp/nndiary hides /home/horn/Repos/el/emacs/lisp/gnus/nndiary
~/Repos/el/gnus/lisp/gnus-diary hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-diary
~/Repos/el/gnus/lisp/nnfolder hides /home/horn/Repos/el/emacs/lisp/gnus/nnfolder
~/Repos/el/gnus/lisp/gnus-art hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-art
~/Repos/el/gnus/lisp/gnus-demon hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-demon
~/Repos/el/gnus/lisp/mml-sec hides /home/horn/Repos/el/emacs/lisp/gnus/mml-sec
~/Repos/el/gnus/lisp/nnir hides /home/horn/Repos/el/emacs/lisp/gnus/nnir
~/Repos/el/gnus/lisp/mm-partial hides /home/horn/Repos/el/emacs/lisp/gnus/mm-partial
~/Repos/el/gnus/lisp/gnus-registry hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-registry
~/Repos/el/gnus/lisp/gnus-icalendar hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-icalendar
~/Repos/el/gnus/lisp/compface hides /home/horn/Repos/el/emacs/lisp/gnus/compface
~/Repos/el/gnus/lisp/gnus-fun hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-fun
~/Repos/el/gnus/lisp/gnus-start hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-start
~/Repos/el/gnus/lisp/smiley hides /home/horn/Repos/el/emacs/lisp/gnus/smiley
~/Repos/el/gnus/lisp/gnus-picon hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-picon
~/Repos/el/gnus/lisp/spam-report hides /home/horn/Repos/el/emacs/lisp/gnus/spam-report
~/Repos/el/gnus/lisp/nntp hides /home/horn/Repos/el/emacs/lisp/gnus/nntp
~/Repos/el/gnus/lisp/nnnil hides /home/horn/Repos/el/emacs/lisp/gnus/nnnil
~/Repos/el/gnus/lisp/nndir hides /home/horn/Repos/el/emacs/lisp/gnus/nndir
~/Repos/el/gnus/lisp/gnus-srvr hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-srvr
~/Repos/el/gnus/lisp/smime hides /home/horn/Repos/el/emacs/lisp/gnus/smime
~/Repos/el/gnus/lisp/nnvirtual hides /home/horn/Repos/el/emacs/lisp/gnus/nnvirtual
~/Repos/el/gnus/lisp/gnus-notifications hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-notifications
~/Repos/el/gnus/lisp/nnspool hides /home/horn/Repos/el/emacs/lisp/gnus/nnspool
~/Repos/el/gnus/lisp/gnus-group hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-group
~/Repos/el/gnus/lisp/gnus-bcklg hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-bcklg
~/Repos/el/gnus/lisp/gnus-util hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-util
~/Repos/el/gnus/lisp/gnus-sieve hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-sieve
~/Repos/el/gnus/lisp/nndraft hides /home/horn/Repos/el/emacs/lisp/gnus/nndraft
~/Repos/el/gnus/lisp/nnagent hides /home/horn/Repos/el/emacs/lisp/gnus/nnagent
~/Repos/el/gnus/lisp/gnus-spec hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-spec
~/Repos/el/gnus/lisp/gnus-bookmark hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-bookmark
~/Repos/el/gnus/lisp/mml1991 hides /home/horn/Repos/el/emacs/lisp/gnus/mml1991
~/Repos/el/gnus/lisp/rfc2231 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2231
~/Repos/el/gnus/lisp/yenc hides /home/horn/Repos/el/emacs/lisp/gnus/yenc
~/Repos/el/gnus/lisp/gnus-undo hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-undo
~/Repos/el/gnus/lisp/ecomplete hides /home/horn/Repos/el/emacs/lisp/gnus/ecomplete
~/Repos/el/gnus/lisp/legacy-gnus-agent hides /home/horn/Repos/el/emacs/lisp/gnus/legacy-gnus-agent
~/Repos/el/gnus/lisp/utf7 hides /home/horn/Repos/el/emacs/lisp/gnus/utf7
~/Repos/el/gnus/lisp/rtree hides /home/horn/Repos/el/emacs/lisp/gnus/rtree
~/Repos/el/gnus/lisp/gnus-uu hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-uu
~/Repos/el/gnus/lisp/gnus-ml hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-ml
~/Repos/el/gnus/lisp/sieve hides /home/horn/Repos/el/emacs/lisp/gnus/sieve
~/Repos/el/gnus/lisp/gnus hides /home/horn/Repos/el/emacs/lisp/gnus/gnus
~/Repos/el/gnus/lisp/mml hides /home/horn/Repos/el/emacs/lisp/gnus/mml
~/Repos/el/gnus/lisp/message hides /home/horn/Repos/el/emacs/lisp/gnus/message
~/Repos/el/gnus/lisp/mml-smime hides /home/horn/Repos/el/emacs/lisp/gnus/mml-smime
~/Repos/el/gnus/lisp/gnus-eform hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-eform
~/Repos/el/gnus/lisp/gnus-agent hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-agent
~/Repos/el/gnus/lisp/gnus-logic hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-logic
~/Repos/el/gnus/lisp/mm-extern hides /home/horn/Repos/el/emacs/lisp/gnus/mm-extern
~/Repos/el/gnus/lisp/nndoc hides /home/horn/Repos/el/emacs/lisp/gnus/nndoc
~/Repos/el/gnus/lisp/sieve-manage hides /home/horn/Repos/el/emacs/lisp/gnus/sieve-manage
~/Repos/el/gnus/lisp/mm-decode hides /home/horn/Repos/el/emacs/lisp/gnus/mm-decode
~/Repos/el/gnus/lisp/starttls hides /home/horn/Repos/el/emacs/lisp/gnus/starttls
~/Repos/el/gnus/lisp/gnus-dired hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-dired
~/Repos/el/gnus/lisp/nnbabyl hides /home/horn/Repos/el/emacs/lisp/gnus/nnbabyl
~/Repos/el/gnus/lisp/nnmbox hides /home/horn/Repos/el/emacs/lisp/gnus/nnmbox
~/Repos/el/gnus/lisp/gnus-win hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-win
~/Repos/el/gnus/lisp/gnus-async hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-async
~/Repos/el/gnus/lisp/mm-url hides /home/horn/Repos/el/emacs/lisp/gnus/mm-url
~/Repos/el/gnus/lisp/gnus-html hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-html
~/Repos/el/gnus/lisp/gssapi hides /home/horn/Repos/el/emacs/lisp/gnus/gssapi
~/Repos/el/gnus/lisp/mml2015 hides /home/horn/Repos/el/emacs/lisp/gnus/mml2015
~/Repos/el/gnus/lisp/nnrss hides /home/horn/Repos/el/emacs/lisp/gnus/nnrss
~/Repos/el/gnus/lisp/gnus-mh hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-mh
~/Repos/el/gnus/lisp/gnus-sum hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-sum
~/Repos/el/gnus/lisp/nnweb hides /home/horn/Repos/el/emacs/lisp/gnus/nnweb
~/Repos/el/gnus/lisp/mail-prsvr hides /home/horn/Repos/el/emacs/lisp/gnus/mail-prsvr
~/Repos/el/gnus/lisp/nnmairix hides /home/horn/Repos/el/emacs/lisp/gnus/nnmairix
~/Repos/el/gnus/lisp/plstore hides /home/horn/Repos/el/emacs/lisp/gnus/plstore
~/Repos/el/gnus/lisp/rfc2045 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2045
~/Repos/el/gnus/lisp/gnus-msg hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-msg
~/Repos/el/gnus/lisp/spam-wash hides /home/horn/Repos/el/emacs/lisp/gnus/spam-wash
~/Repos/el/gnus/lisp/gnus-score hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-score
~/Repos/el/gnus/lisp/mm-uu hides /home/horn/Repos/el/emacs/lisp/gnus/mm-uu
~/Repos/el/gnus/lisp/spam hides /home/horn/Repos/el/emacs/lisp/gnus/spam
~/Repos/el/gnus/lisp/mm-view hides /home/horn/Repos/el/emacs/lisp/gnus/mm-view
~/Repos/el/gnus/lisp/sieve-mode hides /home/horn/Repos/el/emacs/lisp/gnus/sieve-mode
~/Repos/el/gnus/lisp/html2text hides /home/horn/Repos/el/emacs/lisp/gnus/html2text
~/Repos/el/gnus/lisp/gnus-ems hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-ems
~/Repos/el/gnus/lisp/registry hides /home/horn/Repos/el/emacs/lisp/gnus/registry
~/Repos/el/gnus/lisp/auth-source hides /home/horn/Repos/el/emacs/lisp/gnus/auth-source
~/Repos/el/gnus/lisp/gravatar hides /home/horn/Repos/el/emacs/lisp/gnus/gravatar
~/Repos/el/gnus/lisp/flow-fill hides /home/horn/Repos/el/emacs/lisp/gnus/flow-fill
~/Repos/el/gnus/lisp/gmm-utils hides /home/horn/Repos/el/emacs/lisp/gnus/gmm-utils
~/Repos/el/gnus/lisp/mailcap hides /home/horn/Repos/el/emacs/lisp/gnus/mailcap
~/Repos/el/gnus/lisp/gnus-delay hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-delay
~/Repos/el/gnus/lisp/mm-bodies hides /home/horn/Repos/el/emacs/lisp/gnus/mm-bodies
~/Repos/el/gnus/lisp/mm-archive hides /home/horn/Repos/el/emacs/lisp/gnus/mm-archive
~/Repos/el/gnus/lisp/rfc1843 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc1843
~/Repos/el/gnus/lisp/gnus-kill hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-kill
~/Repos/el/gnus/lisp/qp hides /home/horn/Repos/el/emacs/lisp/gnus/qp
~/Repos/el/gnus/lisp/score-mode hides /home/horn/Repos/el/emacs/lisp/gnus/score-mode
~/Repos/el/gnus/lisp/gnus-topic hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-topic
~/Repos/el/gnus/lisp/gnus-cache hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cache
~/Repos/el/gnus/lisp/nnmail hides /home/horn/Repos/el/emacs/lisp/gnus/nnmail
~/Repos/el/gnus/lisp/gnus-vm hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-vm
~/Repos/el/gnus/lisp/gnus-sync hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-sync
~/Repos/el/gnus/lisp/nnoo hides /home/horn/Repos/el/emacs/lisp/gnus/nnoo
~/Repos/el/gnus/lisp/nnregistry hides /home/horn/Repos/el/emacs/lisp/gnus/nnregistry
~/Repos/el/gnus/lisp/gnus-dup hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-dup
~/Repos/el/gnus/lisp/parse-time hides /home/horn/Repos/el/emacs/lisp/calendar/parse-time
~/Repos/el/gnus/lisp/time-date hides /home/horn/Repos/el/emacs/lisp/calendar/time-date

Features:
(shadow emacsbug tabify zeal-at-point help-at-pt rcirc-color
rcirc-controls rcirc-late-fix rcirc goto-addr org-rmail org-mhe org-irc
org-info org-gnus org-docview doc-view org-bibtex bibtex org-bbdb
org-w3m tex-info texinfo canlock magit-key-mode magit view
git-rebase-mode gnus-dired eieio-opt hippie-exp flow-fill ag vc-svn
find-dired ido s ucs-normalize reftex-sel reftex-ref reftex-parse
reftex-toc pdf-sync pdf-annot pdf-outline pdf-links pdf-history
autorevert filenotify pdf-isearch pdf-misc pdf-occur tablist
tablist-filter semantic/wisent/comp semantic/wisent
semantic/wisent/wisent semantic/util-modes semantic/util semantic
semantic/tag semantic/lex semantic/fw mode-local cedet texmathp vc-hg
preview prv-emacs auto-dictionary flyspell ispell tex-buf reftex-dcr
reftex-auc reftex reftex-vars font-latex latex tex-style tex dbus crm
tex-mode latexenc markdown-mode git-commit-mode log-edit pcvs-util
add-log misearch multi-isearch xterm pkg-info lisp-mnt epl speedbar
sb-image ezimage dframe vc vc-dispatcher vc-git diff-mode adaptive-wrap
filecache gnus-fun shr-color color gnus-dup mailalias smtpmail sendmail
url-http url-gw url-auth sort gnus-cite smiley shr dom subr-x mm-archive
gnus-async gnus-bcklg qp gnus-ml hl-line nndraft nnmh rot13 utf-7 gnutls
network-stream nsm starttls nnml nnnil gnus-agent gnus-srvr gnus-score
score-mode nnvirtual gnus-cache gnus-demon nntp spam spam-stat gnus-uu
yenc gnus-msg gnus-gravatar mail-extr gravatar gnus-topic nnir
gnus-registry registry eieio-base th-private company-files
company-oddmuse company-keywords company-etags company-gtags
company-dabbrev-code company-dabbrev company-capf company-cmake
company-ropemacs company-xcode company-clang company-semantic
company-eclim company-template company-css company-nxml company-bbdb
highlight-parentheses company finder-inf stratego-mode greql-mode
tg-mode generic preview-latex tex-site auto-loads cider tramp-sh
cider-mode cider-repl cider-eldoc cider-interaction arc-mode
archive-mode cider-doc org-table cider-test cider-stacktrace
cider-client nrepl-client queue cider-util ewoc etags xref clojure-mode
imenu paredit aggressive-indent names edebug epa-file epa epg rdictcc
ox-reveal ox-latex ox-icalendar ox-html ox-ascii ox-publish ox
org-element google-contacts-message google-contacts derived url-cache
google-oauth google-contacts-gnus gnus-art mm-uu mml2015 mm-view
mml-smime smime dig gnus-sum gnus-group gnus-undo gnus-start gnus-cloud
nnimap nnmail mail-source tls utf7 netrc nnoo parse-time gnus-spec
gnus-int gnus-range gnus-win gnus gnus-ems gnus-compat nnheader em-term
term ehelp esh-opt esh-ext esh-util highlight-symbol boxquote rect
ecomplete message rfc822 mml mml-sec mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev mail-utils
gmm-utils mailheader edit-server server haskell-yas yasnippet help-mode
cl disp-table pdf-tools cus-edit cus-start cus-load pdf-view jka-compr
pdf-cache pdf-info tq pdf-util image-mode browse-kill-ring recentf
tree-widget wid-edit helm-projectile helm-files image-dired tramp
tramp-compat tramp-loaddefs trampver shell dired-x dired-aux ffap
helm-tags helm-bookmark helm-adaptive helm-info helm-net browse-url xml
url url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util url-parse auth-source gnus-util mm-util mail-prsvr
password-cache url-vars mailcap bookmark pp helm-help helm-org org
org-macro org-footnote org-pcomplete pcomplete org-list org-faces
org-entities noutline outline 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 format-spec find-func cal-menu calendar
cal-loaddefs helm-external helm-buffers helm-match-plugin helm-grep
helm-regexp helm-plugin grep helm-elscreen helm-utils dired compile
comint ansi-color ring helm-locate helm cl-macs helm-source eieio-compat
eieio byte-opt gv bytecomp byte-compile cl-extra seq cconv eieio-core
cl-generic pcase helm-config async-bytecomp async helm-aliases
projectile ibuf-ext ibuffer thingatpt easy-mmode iedit iedit-lib
cap-words superword subword saveplace savehist paren icomplete mb-depth
smart-mode-line-light-theme rich-minority smart-mode-line mule-util dash
rx bs windmove elec-pair gnus-load tsdh-light-theme edmacro kmacro
cl-loaddefs cl-lib memory-usage-autoloads advice help-fns info easymenu
package epg-config time-date tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel x-win x-dnd 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 cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese 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 make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 1562617 195734)
 (symbols 48 70882 13)
 (miscs 40 2048 4175)
 (strings 32 277103 21365)
 (string-bytes 1 8958693)
 (vectors 16 101169)
 (vector-slots 8 2348859 220925)
 (floats 8 3017 1660)
 (intervals 56 53524 5927)
 (buffers 976 116)
 (heap 1024 148219 186770))

bug#19988: 25.0.50; Drag events ending in different frame

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Tue, 03 Mar 2015 15:30:22 +0100
> 
> The info docs describe the components of drag-events as
> 
> ,----[ (info "(elisp)Drag Events") ]
> | (EVENT-TYPE
> |       (WINDOW1 START-POSITION)
> |       (WINDOW2 END-POSITION))
> `----
> 
> where WINDOW1 is the window where the drag started and WINDOW2 is the
> window where the drag ended.
> 
> However, that's not correct in case the drag starts in one emacs frame
> and ends in another emacs frame.  In those cases, WINDOW2 is the frame
> containing WINDOW1.
> 
> Is there a reason why drag events cannot work across different frames of
> the very same Emacs instance?

Not sure why, but it looks like this is by design.  The comment in
xterm.c and w32term.c says:

	    /* If mouse was grabbed on a frame, give coords for that frame
	       even if the mouse is now outside it.  */

If this is only about the case when the drag ends outside of any Emacs
frame, then we could amend the code to cover the case that the drag
ends on an Emacs frame.  The current code doesn't check whether we the
button-up event was received in an Emacs frame.

bug#19988: 25.0.50; Drag events ending in different frame

[Stefan Monnier]

> If this is only about the case when the drag ends outside of any Emacs
> frame, then we could amend the code to cover the case that the drag
> ends on an Emacs frame.  The current code doesn't check whether we the
> button-up event was received in an Emacs frame.

FWIW, the current behavior is probably useful in the case where the drag
is used in order to select a region.  IOW, we should probably include
*both* informations.


        Stefan

bug#19988: 25.0.50; Drag events ending in different frame

[Tassilo Horn]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> If this is only about the case when the drag ends outside of any Emacs
>> frame, then we could amend the code to cover the case that the drag
>> ends on an Emacs frame.  The current code doesn't check whether we the
>> button-up event was received in an Emacs frame.

That would be nice.

> FWIW, the current behavior is probably useful in the case where the drag
> is used in order to select a region.  IOW, we should probably include
> *both* informations.

I don't get your statement.  When selecting a region, you're restricted
to one window anyway, no?  And that situation is already covered as one
would expect.

Bye,
Tassilo

bug#19988: 25.0.50; Drag events ending in different frame

[martin rudalics]

 > Is there a reason why drag events cannot work across different frames of
 > the very same Emacs instance?

They could but it's a bit tricky when frames overlap.  And probably some
routines would have to be rewritten because they expect events to happen
on the selected frame.

 > Background: I've written a command that uses drag events to swap buffers
 > of two Emacs windows:

I'd rewrite it (sloppily) as follows:

(defun th/swap-window-buffers-by-dnd (drag-event)
   "Swaps the buffers displayed in the DRAG-EVENT's start and end
window."
   (interactive "e")
   (let ((start-win (cl-caadr drag-event))
	(end-win   (cl-caaddr drag-event)))

     (unless (window-live-p end-win)
       (let* ((selected-frame (selected-frame))
	     (frames (delq selected-frame (frame-list)))
	     position frame window)
	(unwind-protect
	    (catch 'found
	      (while frames
		(select-frame (car frames))
		(setq position (mouse-position))
		(setq window (window-at (cadr position) (cddr position)))
		(when (window-live-p window)
		  (setq end-win window)
		  (throw 'found t))
		(setq frames (cdr frames))))
	  (select-frame selected-frame))))

     (when (and (windowp start-win)
	       (windowp end-win)
	       (not (eq start-win end-win)))
       (let ((bs (window-buffer start-win))
	    (be (window-buffer end-win)))
	(set-window-buffer start-win be)
	(set-window-buffer end-win bs)))))

(global-set-key (kbd "<C-S-drag-mouse-1>")
		#'th/swap-window-buffers-by-dnd)

martin

bug#19988: 25.0.50; Drag events ending in different frame

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Tassilo Horn <tsdh@gnu.org>, 19988@debbugs.gnu.org
> Date: Tue, 03 Mar 2015 23:28:25 -0500
> 
> > If this is only about the case when the drag ends outside of any Emacs
> > frame, then we could amend the code to cover the case that the drag
> > ends on an Emacs frame.  The current code doesn't check whether we the
> > button-up event was received in an Emacs frame.
> 
> FWIW, the current behavior is probably useful in the case where the drag
> is used in order to select a region.  IOW, we should probably include
> *both* informations.

How do we include both in a backward-compatible way?

bug#19988: 25.0.50; Drag events ending in different frame

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  19988@debbugs.gnu.org
> Date: Wed, 04 Mar 2015 08:03:07 +0100
> 
> > FWIW, the current behavior is probably useful in the case where the drag
> > is used in order to select a region.  IOW, we should probably include
> > *both* informations.
> 
> I don't get your statement.  When selecting a region, you're restricted
> to one window anyway, no?

Stefan thinks about dragging the mouse outside of the frame, to
another frame: you'd still want to select only text in the window you
started.

> And that situation is already covered as one would expect.

What do you mean by "as one would expect"?  On my machine, the
behavior is unreasonable: the wrong part of text is selected.

So, Stefan, it looks like this doesn't work with the current code,
either.

bug#19988: 25.0.50; Drag events ending in different frame

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> > FWIW, the current behavior is probably useful in the case where the
>> > drag is used in order to select a region.  IOW, we should probably
>> > include *both* informations.
>> 
>> I don't get your statement.  When selecting a region, you're
>> restricted to one window anyway, no?
>
> Stefan thinks about dragging the mouse outside of the frame, to
> another frame: you'd still want to select only text in the window you
> started.
>
>> And that situation is already covered as one would expect.
>
> What do you mean by "as one would expect"?  On my machine, the
> behavior is unreasonable: the wrong part of text is selected.

When I select a region by dragging Mouse-1 starting at the "selected."
above, as soon as the mouse cursor leaves the emacs frame, the region
won't grow or shrink anymore until I enter the frame and window again.
And when I release the drag outside of the frame and window where I
started, the final region is the last one before leaving the
frame/window.  That's pretty much what I'd expect except that releasing
the drag outside of the start frame/window inactivates the region.

Bye,
Tassilo

bug#19988: 25.0.50; Drag events ending in different frame

[Tassilo Horn]

martin rudalics <rudalics@gmx.at> writes:

Hi Martin,

>> Is there a reason why drag events cannot work across different frames
>> of the very same Emacs instance?
>
> They could but it's a bit tricky when frames overlap.  And probably
> some routines would have to be rewritten because they expect events to
> happen on the selected frame.

Ok.  I think that would still be a nice enhancement although not
pressing.  At least your rewrite of my function isn't really obvious to
me and probably most users.  And it also behaves wrongly in some
situations with overlapping frames.

Bye,
Tassilo

bug#19988: 25.0.50; Drag events ending in different frame

[Stefan Monnier]

> How do we include both in a backward-compatible way?

Good question.  Maybe we can return only one of the two and find a way
to implement a function that computes the other from the one
that's returned.

> When I select a region by dragging Mouse-1 starting at the "selected."
> above, as soon as the mouse cursor leaves the emacs frame, the region
> won't grow or shrink anymore until I enter the frame and window again.

Indeed, sorry.  Dragging keeps working when you drag a mode-line but not
when you drag a region.  Not sure why.  Looks like a bug to me.

Actually, it's more subtle than that: if I move into another frame which
hides part of the selected window, the drag keeps working (as long as
I stay within the bounds of the originally selected window, even though
I don't get to see some of those bounds because they're hidden by
another frame).

Oh, and there's yet another subtlety: if, during the drag, you move the
mouse out of the selected frame, the drag seems to freeze indeed, but if
you then move your mouse higher/lower than the frame the text gets
scrolled and the drag does take place (even if you release the mouse
while it's outside of the originally selected frame/window).


        Stefan

bug#19988: 25.0.50; Drag events ending in different frame

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: monnier@IRO.UMontreal.CA,  19988@debbugs.gnu.org
> Date: Wed, 04 Mar 2015 22:09:42 +0100
> 
> >> And that situation is already covered as one would expect.
> >
> > What do you mean by "as one would expect"?  On my machine, the
> > behavior is unreasonable: the wrong part of text is selected.
> 
> When I select a region by dragging Mouse-1 starting at the "selected."
> above, as soon as the mouse cursor leaves the emacs frame, the region
> won't grow or shrink anymore until I enter the frame and window again.
> And when I release the drag outside of the frame and window where I
> started, the final region is the last one before leaving the
> frame/window.  That's pretty much what I'd expect except that releasing
> the drag outside of the start frame/window inactivates the region.

I wish I saw something like that, but I don't.  Could be a Windows
specific issue, though.

In any case, that doesn't explain the "already covered" part: isn't
that "covered" _because_ we return the initial frame as the end of
drag?

bug#19988: 25.0.50; Drag events ending in different frame

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> And that situation is already covered as one would expect.
>> >
>> > What do you mean by "as one would expect"?  On my machine, the
>> > behavior is unreasonable: the wrong part of text is selected.
>> 
>> When I select a region by dragging Mouse-1 starting at the "selected."
>> above, as soon as the mouse cursor leaves the emacs frame, the region
>> won't grow or shrink anymore until I enter the frame and window again.
>> And when I release the drag outside of the frame and window where I
>> started, the final region is the last one before leaving the
>> frame/window.  That's pretty much what I'd expect except that releasing
>> the drag outside of the start frame/window inactivates the region.
>
> I wish I saw something like that, but I don't.  Could be a Windows
> specific issue, though.
>
> In any case, that doesn't explain the "already covered" part: isn't
> that "covered" _because_ we return the initial frame as the end of
> drag?

Now I get a different behavior as described yesterday [1]: when my drag
is released outside of the frame where it startet, no region is selected
and the mark is set at the start position of the selected text.  I
really wonder why I got a different behavior.

Having the initial frame as the drag end has to do with that, indeed,
but only because (posn-point (event-end click)) returns nil in this case
(see `mouse-set-region').  If it had the window of another frame as drag
end instead, it would use as region the position in the start window and
the correspondence of the end in the target window in the source window.
That would be nonsense if both windows show a different buffer, but if
they showed the same buffer that could infact be quite reasonable and
convenient to select large regions without needing to scroll.  (Of
course, that won't work if my drag leaves the start window on top or at
the bottom which triggeres scrolling...)

Anyway, if drag events would return the actual end window even if that's
on another frame (and the start frame only in case the drag ended
external to emacs), then `mouse-set-region' would need to check if start
and end window are the same and else do nothing.  Doing that right now
wouldn't hurt either, as it would inhibit setting the mark at the start
of the region which won't be selected anyhow.

Bye,
Tassilo

[1] I only updated my emacs checkout just now but there seem to be no
relevant changes from yesterday morning's version.  And I did a
bootstrap yesterday evening...

bug#19988: 25.0.50; Drag events ending in different frame

[martin rudalics]

 > When I select a region by dragging Mouse-1 starting at the "selected."
 > above, as soon as the mouse cursor leaves the emacs frame, the region
 > won't grow or shrink anymore until I enter the frame and window again.
 > And when I release the drag outside of the frame and window where I
 > started, the final region is the last one before leaving the
 > frame/window.

With emacs -Q?  That's very strange.  I've never seen such behavior
anywhere, neither with Emacs nor with any other application I use.

 > That's pretty much what I'd expect except that releasing
 > the drag outside of the start frame/window inactivates the region.

But how can you possibly mouse-extend the region if your mouse cursor
has to stay within the window?

martin

bug#19988: 25.0.50; Drag events ending in different frame

[martin rudalics]

 > Actually, it's more subtle than that: if I move into another frame which
 > hides part of the selected window, the drag keeps working (as long as
 > I stay within the bounds of the originally selected window, even though
 > I don't get to see some of those bounds because they're hidden by
 > another frame).

But that's expected?

 > Oh, and there's yet another subtlety: if, during the drag, you move the
 > mouse out of the selected frame, the drag seems to freeze indeed, but if
 > you then move your mouse higher/lower than the frame the text gets
 > scrolled and the drag does take place (even if you release the mouse
 > while it's outside of the originally selected frame/window).

And that's the behavior I see with all applications that allow expanding
highlighted text with the mouse.

martin

bug#19988: 25.0.50; Drag events ending in different frame

[martin rudalics]

 > Ok.  I think that would still be a nice enhancement although not
 > pressing.

It's tricky as I explained earlier.  Emacs knows about the x/y-extents
of its visible frames but has no idea about the Z order they appear in.
So if you have two overlapping target frames, how would it know which
one to choose?

 > At least your rewrite of my function isn't really obvious to
 > me and probably most users.

Basically you should rewrite you function using mouse tracking.  Mine is
only a hack to work within the frame of what you wrote before.

 > And it also behaves wrongly in some
 > situations with overlapping frames.

Expected.  See above.

martin

bug#19988: 25.0.50; Drag events ending in different frame

[Eli Zaretskii]

> Date: Thu, 05 Mar 2015 05:37:58 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 19988@debbugs.gnu.org
> 
> > When I select a region by dragging Mouse-1 starting at the "selected."
> > above, as soon as the mouse cursor leaves the emacs frame, the region
> > won't grow or shrink anymore until I enter the frame and window again.
> > And when I release the drag outside of the frame and window where I
> > started, the final region is the last one before leaving the
> > frame/window.  That's pretty much what I'd expect except that releasing
> > the drag outside of the start frame/window inactivates the region.
> 
> I wish I saw something like that, but I don't.  Could be a Windows
> specific issue, though.

No, it's not Windows-specific.  Crystal ball says if you make your
scroll bars appear on the right of the window, you, too, will see
abnormal behavior when mouse exits outside of the frame to the right.

Now fixed in commit 1be3bd0.

bug#19988: 25.0.50; Drag events ending in different frame

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: monnier@IRO.UMontreal.CA,  19988@debbugs.gnu.org
> Date: Thu, 05 Mar 2015 08:19:28 +0100
> 
> Now I get a different behavior as described yesterday [1]: when my drag
> is released outside of the frame where it startet, no region is selected
> and the mark is set at the start position of the selected text.

That's not what I see.  For me, the region extension ends when the
mouse goes out of the frame, and the region stays as it was at the
last extension.

Through which side of the frame do you exit the frame while dragging?

bug#19988: 25.0.50; Drag events ending in different frame

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Eli Zaretskii <eliz@gnu.org>, 19988@debbugs.gnu.org
> Date: Wed, 04 Mar 2015 17:58:46 -0500
> 
> > How do we include both in a backward-compatible way?
> 
> Good question.  Maybe we can return only one of the two and find a way
> to implement a function that computes the other from the one
> that's returned.

Yes, that would work.

> > When I select a region by dragging Mouse-1 starting at the "selected."
> > above, as soon as the mouse cursor leaves the emacs frame, the region
> > won't grow or shrink anymore until I enter the frame and window again.
> 
> Indeed, sorry.  Dragging keeps working when you drag a mode-line but not
> when you drag a region.  Not sure why.  Looks like a bug to me.

The code looks like it was explicitly programmed to do this.

> Actually, it's more subtle than that: if I move into another frame which
> hides part of the selected window, the drag keeps working (as long as
> I stay within the bounds of the originally selected window, even though
> I don't get to see some of those bounds because they're hidden by
> another frame).

This doesn't happen on my system.  Could be toolkit-specific.

> Oh, and there's yet another subtlety: if, during the drag, you move the
> mouse out of the selected frame, the drag seems to freeze indeed, but if
> you then move your mouse higher/lower than the frame the text gets
> scrolled and the drag does take place (even if you release the mouse
> while it's outside of the originally selected frame/window).

Yes, and that's expected, I think.

bug#19988: 25.0.50; Drag events ending in different frame

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> > When I select a region by dragging Mouse-1 starting at the "selected."
>> > above, as soon as the mouse cursor leaves the emacs frame, the region
>> > won't grow or shrink anymore until I enter the frame and window again.
>> > And when I release the drag outside of the frame and window where I
>> > started, the final region is the last one before leaving the
>> > frame/window.  That's pretty much what I'd expect except that releasing
>> > the drag outside of the start frame/window inactivates the region.
>> 
>> I wish I saw something like that, but I don't.  Could be a Windows
>> specific issue, though.
>
> No, it's not Windows-specific.  Crystal ball says if you make your
> scroll bars appear on the right of the window, you, too, will see
> abnormal behavior when mouse exits outside of the frame to the right.

I don't have scroll-bars at all. ;-)

> Now fixed in commit 1be3bd0.

Bye,
Tassilo

bug#19988: 25.0.50; Drag events ending in different frame

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> Now I get a different behavior as described yesterday [1]: when my drag
>> is released outside of the frame where it startet, no region is selected
>> and the mark is set at the start position of the selected text.
>
> That's not what I see.  For me, the region extension ends when the
> mouse goes out of the frame, and the region stays as it was at the
> last extension.
>
> Through which side of the frame do you exit the frame while dragging?

It doesn't matter, the behavior is as described above.  As said in my
other mail, I don't use scroll-bars.  But even with emacs -Q with
scroll-bars on the right compiled from commit cbc9d8d I have the same
behavior as above.

Bye,
Tassilo

bug#19988: 25.0.50; Drag events ending in different frame

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: monnier@IRO.UMontreal.CA,  19988@debbugs.gnu.org
> Date: Thu, 05 Mar 2015 21:07:41 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Now I get a different behavior as described yesterday [1]: when my drag
> >> is released outside of the frame where it startet, no region is selected
> >> and the mark is set at the start position of the selected text.
> >
> > That's not what I see.  For me, the region extension ends when the
> > mouse goes out of the frame, and the region stays as it was at the
> > last extension.
> >
> > Through which side of the frame do you exit the frame while dragging?
> 
> It doesn't matter, the behavior is as described above.  As said in my
> other mail, I don't use scroll-bars.  But even with emacs -Q with
> scroll-bars on the right compiled from commit cbc9d8d I have the same
> behavior as above.

So you are saying that you see the region extend to the edge of the
text as long as you drag the mouse inside the frame, then shrink back
when the mouse is dragged outside of the frame?

bug#19988: 25.0.50; Drag events ending in different frame

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> Now I get a different behavior as described yesterday [1]: when my
>> >> drag is released outside of the frame where it startet, no region
>> >> is selected and the mark is set at the start position of the
>> >> selected text.
>> >
>> > That's not what I see.  For me, the region extension ends when the
>> > mouse goes out of the frame, and the region stays as it was at the
>> > last extension.
>> >
>> > Through which side of the frame do you exit the frame while dragging?
>> 
>> It doesn't matter, the behavior is as described above.  As said in my
>> other mail, I don't use scroll-bars.  But even with emacs -Q with
>> scroll-bars on the right compiled from commit cbc9d8d I have the same
>> behavior as above.
>
> So you are saying that you see the region extend to the edge of the
> text as long as you drag the mouse inside the frame, then shrink back
> when the mouse is dragged outside of the frame?

Not exactly.

  1. As long as I drag inside the start window, the region
     extends/shrinks.  When releasing the mouse button, the region is
     from the start point to the position where I released the button
     and is active, i.e., highlighted by tmm.

  2. When I drag into a different window of the left or right of the
     start window *showing the same buffer*, the region (highlighting)
     freezes at the position where the start window was left.  When I
     release the mouse button in the other window, the region suddenly
     resized from the start position to the end position of the other
     window.  That's actually a cool feature as it allows to select
     large regions without scrolling.

  3. When I drag into a different window on the right of the start
     window which shows a different buffer than the start window, the
     region (highlighting) freezes as soon as I leave the start window.
     When I release the mouse button, the region suddenly becomes
     start-position to top of the buffer.

  4. Doing the same as in 3. but dragging to the window on the left,
     when releasing the mouse button the region suddenly becomes start
     position to "somewhere above the end of the marked region which
     froze when leaving the start window", i.e., the region-end jumps
     up.  Sometimes even higher than the region-start, sometimes below
     it.  Sorry, I don't see any system here...

  5. Dragging outside of the frame (which has only one window) freezes
     the selected region as soon as the mouse leaves the frame.  It
     doesn't matter if I leave to the left or to the right.  When I then
     release the mouse button outside of the frame, the region vanishes
     and the mark is set at the start position of the drag.

So it seems you get a different behavior in at least case 5 (i.e., your
region doesn't vanish).  Not sure what might be the difference but I can
reproduce that using emacs -Q.

GNU Emacs 25.0.50.4 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.9) of
2015-03-06, commit bfebebbc72c6a6ea375c6e8ed7f8641b25439770

Bye,
Tassilo

bug#19988: 25.0.50; Drag events ending in different frame

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: monnier@IRO.UMontreal.CA,  19988@debbugs.gnu.org
> Date: Fri, 06 Mar 2015 08:12:14 +0100
> 
>   3. When I drag into a different window on the right of the start
>      window which shows a different buffer than the start window, the
>      region (highlighting) freezes as soon as I leave the start window.
>      When I release the mouse button, the region suddenly becomes
>      start-position to top of the buffer.

What happens when you release the mouse button depend on which line in
the original window you were.  If you were on the first line, then
mouse-drag-track (which see) tries to scroll the display, and as
result you end up with the above effect.

>   4. Doing the same as in 3. but dragging to the window on the left,
>      when releasing the mouse button the region suddenly becomes start
>      position to "somewhere above the end of the marked region which
>      froze when leaving the start window", i.e., the region-end jumps
>      up.  Sometimes even higher than the region-start, sometimes below
>      it.  Sorry, I don't see any system here...

Look at mouse-drag-track, and I think things will become clearer.  Not
sure if the logic there is entirely correct, I think it might "assume"
too much when the end event gives no usable position on another frame.

>   5. Dragging outside of the frame (which has only one window) freezes
>      the selected region as soon as the mouse leaves the frame.  It
>      doesn't matter if I leave to the left or to the right.  When I then
>      release the mouse button outside of the frame, the region vanishes
>      and the mark is set at the start position of the drag.
> 
> So it seems you get a different behavior in at least case 5 (i.e., your
> region doesn't vanish).

It does vanish when I release the mouse button.

bug#19988: 25.0.50; Drag events ending in different frame

[Stefan Monnier]

> So if you have two overlapping target frames, how would it know which
> one to choose?

The drag event should return the one that's on top.  Then you can
compute the corresponding location in the lower window if it wants to
using the kind of code you suggested (because it knows it wants that
specific window, not for its stacking order but for other reasons).


        Stefan

bug#19988: 25.0.50; Drag events ending in different frame

[Drew Adams]

>   5. Dragging outside of the frame (which has only one window) freezes
>      the selected region as soon as the mouse leaves the frame.  It
>      doesn't matter if I leave to the left or to the right.  When I then
>      release the mouse button outside of the frame, the region vanishes
>      and the mark is set at the start position of the drag.

I haven't been following this thread. Just wanted to say that I see
this too (#5), and I find it a bit annoying.  Dunno whether anything
can be done about it.

The typical scenario where I run into it is trying to select text
using the mouse and inadvertently moving the mouse slightly outside
the frame.  The region stays selected, even as the mouse is outside
the frame, so I think all is well. 

But as soon as I let go (release `mouse-1'), the selection disappears,
and point moves back where it was - where mark is now set also (empty
region).

bug#19988: 25.0.50; Drag events ending in different frame

[martin rudalics]

 > The typical scenario where I run into it is trying to select text
 > using the mouse and inadvertently moving the mouse slightly outside
 > the frame.  The region stays selected, even as the mouse is outside
 > the frame, so I think all is well.

You _have_ to move outside the frame if you want to scroll the text in
the window and thus enlarge the region.  If the mouse cursor remains in
the window, text won't scroll.  All applications behave like this.

 > But as soon as I let go (release `mouse-1'), the selection disappears,
 > and point moves back where it was - where mark is now set also (empty
 > region).

Because you should move the cursor exactly to the location where you
want `point' to be.  Any position of `point' when the mouse cursor is
outside the frame is specified only by a previous position and the
amount text scrolled.  Emacs is different here because the region cannot
exist without `point'.  Other applications can leave the selection alone
because their equivalent of point doesn't change during mouse dragging.

martin

bug#19988: 25.0.50; Drag events ending in different frame

[martin rudalics]

 > The drag event should return the one that's on top.

The top window is usually the one where the drag started.  We need the
Emacs window not obscured by _any_ other window at the location of the
mouse cursor.  How do we find that window?

 > Then you can
 > compute the corresponding location in the lower window if it wants to
 > using the kind of code you suggested (because it knows it wants that
 > specific window, not for its stacking order but for other reasons).

Any code trying to detect the target window has to do the same
computation.  Mine was only an attempt to do that manually within
Tassilo's original proposal.

martin

bug#19988: 25.0.50; Drag events ending in different frame

[Stefan Monnier]

>> The drag event should return the one that's on top.
> The top window is usually the one where the drag started.

Usually but not always.

> We need the Emacs window not obscured by _any_ other window at the
> location of the mouse cursor.  How do we find that window?

If the top-window at the location of the end-drag is not an Emacs frame,
then any Emacs frame is as good as any other, I think.


        Stefan

bug#19988: 25.0.50; Drag events ending in different frame

[martin rudalics]

 >> The top window is usually the one where the drag started.
 >
 > Usually but not always.

And the window where the drag stops is no always the top window either.

 > If the top-window at the location of the end-drag is not an Emacs frame,
 > then any Emacs frame is as good as any other, I think.

We'd still have to resolve the case where one Emacs frame obscures
another.  So I see no way to resolve this issue consistently without
knowing the Z order of our frames.

martin

bug#19988: 25.0.50; Drag events ending in different frame

[Stefan Monnier]

> We'd still have to resolve the case where one Emacs frame obscures
> another.

If one of the two is the top window (i.e. the one that's actually
visible), then we should use that one, and we should be able to figure
it out at the C level (i.e. it should be the one that is in the event
structure).

If not, then it doesn't really matter if we "get it right" or not.


        Stefan

bug#19988: 25.0.50; Drag events ending in different frame

[martin rudalics]

 > If one of the two is the top window (i.e. the one that's actually
 > visible), then we should use that one,

Detecting whether "one of the two is the top window (i.e. the one that's
actually visible)" requires access to the Z order of windows.  But maybe
I'm missing something all too obvious here.

 > and we should be able to figure
 > it out at the C level (i.e. it should be the one that is in the event
 > structure).

The event structure can only contain what we put into it.  Which window
would you put into this structure after you leave the frame containing
the window where the start event occurred?

 > If not, then it doesn't really matter if we "get it right" or not.

If one frame obscures another, the obscured frame should IMHO not be
considered a valid target.

martin

bug#19988: 25.0.50; Drag events ending in different frame

[Stefan Monnier]

>> If one of the two is the top window (i.e. the one that's actually
>> visible), then we should use that one,
> Detecting whether "one of the two is the top window (i.e. the one that's
> actually visible)" requires access to the Z order of windows.

Not exactly: since this should be done by the C code, it can ask the
window-system, which is the "current window under the mouse pointer".
The result depends on Z ordering, but Emacs doesn't need to know that
Z ordering.

> The event structure can only contain what we put into it.  Which window
> would you put into this structure after you leave the frame containing
> the window where the start event occurred?

The GUI window that's under the mouse pointer (according to the
window-system).

>> If not, then it doesn't really matter if we "get it right" or not.
> If one frame obscures another, the obscured frame should IMHO not be
> considered a valid target.

If they're both obscured by a third window (which does not belong to
us), then I don't think it matters much either way.


        Stefan

bug#19988: 25.0.50; Drag events ending in different frame

[Jan D.]

Stefan Monnier skrev den 2015-03-09 05:34:
>>> If one of the two is the top window (i.e. the one that's actually
>>> visible), then we should use that one,
>> Detecting whether "one of the two is the top window (i.e. the one that's
>> actually visible)" requires access to the Z order of windows.
>
> Not exactly: since this should be done by the C code, it can ask the
> window-system, which is the "current window under the mouse pointer".
> The result depends on Z ordering, but Emacs doesn't need to know that
> Z ordering.
>
>> The event structure can only contain what we put into it.  Which window
>> would you put into this structure after you leave the frame containing
>> the window where the start event occurred?
>
> The GUI window that's under the mouse pointer (according to the
> window-system).
>

XQueryPointer gives you the window.  But for drag-and-drop (depending on 
what protocol is being used), you also need to check if that window 
supports drag-and-drop.

	Jan D.

bug#19988: 25.0.50; Drag events ending in different frame

[martin rudalics]

 > XQueryPointer gives you the window.

I suppose we just need the right Emacs window here.

martin