* bug#19988: 25.0.50; Drag events ending in different frame
@ 2015-03-03 14:30 Tassilo Horn
2015-03-03 20:27 ` Eli Zaretskii
2015-03-04 15:10 ` martin rudalics
0 siblings, 2 replies; 34+ messages in thread
From: Tassilo Horn @ 2015-03-03 14:30 UTC (permalink / raw)
To: 19988
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))
^ permalink raw reply [flat|nested] 34+ messages in thread* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-03 14:30 bug#19988: 25.0.50; Drag events ending in different frame Tassilo Horn @ 2015-03-03 20:27 ` Eli Zaretskii 2015-03-04 4:28 ` Stefan Monnier 2015-03-04 15:10 ` martin rudalics 1 sibling, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2015-03-03 20:27 UTC (permalink / raw) To: Tassilo Horn; +Cc: 19988 > 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-03 20:27 ` Eli Zaretskii @ 2015-03-04 4:28 ` Stefan Monnier 2015-03-04 7:03 ` Tassilo Horn 2015-03-04 17:19 ` Eli Zaretskii 0 siblings, 2 replies; 34+ messages in thread From: Stefan Monnier @ 2015-03-04 4:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 19988, Tassilo Horn > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-04 4:28 ` Stefan Monnier @ 2015-03-04 7:03 ` Tassilo Horn 2015-03-04 17:22 ` Eli Zaretskii 2015-03-04 17:19 ` Eli Zaretskii 1 sibling, 1 reply; 34+ messages in thread From: Tassilo Horn @ 2015-03-04 7:03 UTC (permalink / raw) To: Stefan Monnier; +Cc: 19988 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-04 7:03 ` Tassilo Horn @ 2015-03-04 17:22 ` Eli Zaretskii 2015-03-04 21:09 ` Tassilo Horn 0 siblings, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2015-03-04 17:22 UTC (permalink / raw) To: Tassilo Horn; +Cc: 19988 > 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-04 17:22 ` Eli Zaretskii @ 2015-03-04 21:09 ` Tassilo Horn 2015-03-04 22:58 ` Stefan Monnier ` (2 more replies) 0 siblings, 3 replies; 34+ messages in thread From: Tassilo Horn @ 2015-03-04 21:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 19988 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-04 21:09 ` Tassilo Horn @ 2015-03-04 22:58 ` Stefan Monnier 2015-03-05 8:05 ` martin rudalics 2015-03-05 17:05 ` Eli Zaretskii 2015-03-05 3:37 ` Eli Zaretskii 2015-03-05 8:05 ` martin rudalics 2 siblings, 2 replies; 34+ messages in thread From: Stefan Monnier @ 2015-03-04 22:58 UTC (permalink / raw) To: Tassilo Horn; +Cc: 19988 > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-04 22:58 ` Stefan Monnier @ 2015-03-05 8:05 ` martin rudalics 2015-03-05 17:05 ` Eli Zaretskii 1 sibling, 0 replies; 34+ messages in thread From: martin rudalics @ 2015-03-05 8:05 UTC (permalink / raw) To: Stefan Monnier, Tassilo Horn; +Cc: 19988 > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-04 22:58 ` Stefan Monnier 2015-03-05 8:05 ` martin rudalics @ 2015-03-05 17:05 ` Eli Zaretskii 1 sibling, 0 replies; 34+ messages in thread From: Eli Zaretskii @ 2015-03-05 17:05 UTC (permalink / raw) To: Stefan Monnier; +Cc: 19988, tsdh > 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-04 21:09 ` Tassilo Horn 2015-03-04 22:58 ` Stefan Monnier @ 2015-03-05 3:37 ` Eli Zaretskii 2015-03-05 7:19 ` Tassilo Horn 2015-03-05 17:00 ` Eli Zaretskii 2015-03-05 8:05 ` martin rudalics 2 siblings, 2 replies; 34+ messages in thread From: Eli Zaretskii @ 2015-03-05 3:37 UTC (permalink / raw) To: Tassilo Horn; +Cc: 19988 > 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? ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-05 3:37 ` Eli Zaretskii @ 2015-03-05 7:19 ` Tassilo Horn 2015-03-05 17:02 ` Eli Zaretskii 2015-03-05 17:00 ` Eli Zaretskii 1 sibling, 1 reply; 34+ messages in thread From: Tassilo Horn @ 2015-03-05 7:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 19988 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... ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-05 7:19 ` Tassilo Horn @ 2015-03-05 17:02 ` Eli Zaretskii 2015-03-05 20:07 ` Tassilo Horn 0 siblings, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2015-03-05 17:02 UTC (permalink / raw) To: Tassilo Horn; +Cc: 19988 > 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? ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-05 17:02 ` Eli Zaretskii @ 2015-03-05 20:07 ` Tassilo Horn 2015-03-05 20:15 ` Eli Zaretskii 0 siblings, 1 reply; 34+ messages in thread From: Tassilo Horn @ 2015-03-05 20:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 19988 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-05 20:07 ` Tassilo Horn @ 2015-03-05 20:15 ` Eli Zaretskii 2015-03-06 7:12 ` Tassilo Horn 0 siblings, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2015-03-05 20:15 UTC (permalink / raw) To: Tassilo Horn; +Cc: 19988 > 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? ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-05 20:15 ` Eli Zaretskii @ 2015-03-06 7:12 ` Tassilo Horn 2015-03-06 14:13 ` Eli Zaretskii 2015-03-06 16:09 ` Drew Adams 0 siblings, 2 replies; 34+ messages in thread From: Tassilo Horn @ 2015-03-06 7:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 19988 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-06 7:12 ` Tassilo Horn @ 2015-03-06 14:13 ` Eli Zaretskii 2015-03-06 16:09 ` Drew Adams 1 sibling, 0 replies; 34+ messages in thread From: Eli Zaretskii @ 2015-03-06 14:13 UTC (permalink / raw) To: Tassilo Horn; +Cc: 19988 > 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-06 7:12 ` Tassilo Horn 2015-03-06 14:13 ` Eli Zaretskii @ 2015-03-06 16:09 ` Drew Adams 2015-03-06 18:55 ` martin rudalics 1 sibling, 1 reply; 34+ messages in thread From: Drew Adams @ 2015-03-06 16:09 UTC (permalink / raw) To: Tassilo Horn, Eli Zaretskii; +Cc: 19988 > 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). ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-06 16:09 ` Drew Adams @ 2015-03-06 18:55 ` martin rudalics 0 siblings, 0 replies; 34+ messages in thread From: martin rudalics @ 2015-03-06 18:55 UTC (permalink / raw) To: Drew Adams, Tassilo Horn, Eli Zaretskii; +Cc: 19988 > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-05 3:37 ` Eli Zaretskii 2015-03-05 7:19 ` Tassilo Horn @ 2015-03-05 17:00 ` Eli Zaretskii 2015-03-05 20:01 ` Tassilo Horn 1 sibling, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2015-03-05 17:00 UTC (permalink / raw) To: tsdh; +Cc: 19988 > 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-05 17:00 ` Eli Zaretskii @ 2015-03-05 20:01 ` Tassilo Horn 0 siblings, 0 replies; 34+ messages in thread From: Tassilo Horn @ 2015-03-05 20:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 19988 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-04 21:09 ` Tassilo Horn 2015-03-04 22:58 ` Stefan Monnier 2015-03-05 3:37 ` Eli Zaretskii @ 2015-03-05 8:05 ` martin rudalics 2 siblings, 0 replies; 34+ messages in thread From: martin rudalics @ 2015-03-05 8:05 UTC (permalink / raw) To: Tassilo Horn, Eli Zaretskii; +Cc: 19988 > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-04 4:28 ` Stefan Monnier 2015-03-04 7:03 ` Tassilo Horn @ 2015-03-04 17:19 ` Eli Zaretskii 1 sibling, 0 replies; 34+ messages in thread From: Eli Zaretskii @ 2015-03-04 17:19 UTC (permalink / raw) To: Stefan Monnier; +Cc: 19988, tsdh > 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? ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-03 14:30 bug#19988: 25.0.50; Drag events ending in different frame Tassilo Horn 2015-03-03 20:27 ` Eli Zaretskii @ 2015-03-04 15:10 ` martin rudalics 2015-03-04 21:14 ` Tassilo Horn 1 sibling, 1 reply; 34+ messages in thread From: martin rudalics @ 2015-03-04 15:10 UTC (permalink / raw) To: Tassilo Horn, 19988 > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-04 15:10 ` martin rudalics @ 2015-03-04 21:14 ` Tassilo Horn 2015-03-05 8:06 ` martin rudalics 0 siblings, 1 reply; 34+ messages in thread From: Tassilo Horn @ 2015-03-04 21:14 UTC (permalink / raw) To: martin rudalics; +Cc: 19988 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-04 21:14 ` Tassilo Horn @ 2015-03-05 8:06 ` martin rudalics 2015-03-06 14:37 ` Stefan Monnier 0 siblings, 1 reply; 34+ messages in thread From: martin rudalics @ 2015-03-05 8:06 UTC (permalink / raw) To: Tassilo Horn; +Cc: 19988 > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-05 8:06 ` martin rudalics @ 2015-03-06 14:37 ` Stefan Monnier 2015-03-06 18:55 ` martin rudalics 0 siblings, 1 reply; 34+ messages in thread From: Stefan Monnier @ 2015-03-06 14:37 UTC (permalink / raw) To: martin rudalics; +Cc: 19988, Tassilo Horn > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-06 14:37 ` Stefan Monnier @ 2015-03-06 18:55 ` martin rudalics 2015-03-06 20:19 ` Stefan Monnier 0 siblings, 1 reply; 34+ messages in thread From: martin rudalics @ 2015-03-06 18:55 UTC (permalink / raw) To: Stefan Monnier; +Cc: 19988, Tassilo Horn > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-06 18:55 ` martin rudalics @ 2015-03-06 20:19 ` Stefan Monnier 2015-03-06 21:31 ` martin rudalics 0 siblings, 1 reply; 34+ messages in thread From: Stefan Monnier @ 2015-03-06 20:19 UTC (permalink / raw) To: martin rudalics; +Cc: 19988, Tassilo Horn >> 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-06 20:19 ` Stefan Monnier @ 2015-03-06 21:31 ` martin rudalics 2015-03-07 0:49 ` Stefan Monnier 0 siblings, 1 reply; 34+ messages in thread From: martin rudalics @ 2015-03-06 21:31 UTC (permalink / raw) To: Stefan Monnier; +Cc: 19988, Tassilo Horn >> 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-06 21:31 ` martin rudalics @ 2015-03-07 0:49 ` Stefan Monnier 2015-03-07 9:41 ` martin rudalics 0 siblings, 1 reply; 34+ messages in thread From: Stefan Monnier @ 2015-03-07 0:49 UTC (permalink / raw) To: martin rudalics; +Cc: 19988, Tassilo Horn > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-07 0:49 ` Stefan Monnier @ 2015-03-07 9:41 ` martin rudalics 2015-03-09 4:34 ` Stefan Monnier 0 siblings, 1 reply; 34+ messages in thread From: martin rudalics @ 2015-03-07 9:41 UTC (permalink / raw) To: Stefan Monnier; +Cc: 19988, Tassilo Horn > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-07 9:41 ` martin rudalics @ 2015-03-09 4:34 ` Stefan Monnier 2015-03-09 7:53 ` Jan D. 0 siblings, 1 reply; 34+ messages in thread From: Stefan Monnier @ 2015-03-09 4:34 UTC (permalink / raw) To: martin rudalics; +Cc: 19988, Tassilo Horn >> 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-09 4:34 ` Stefan Monnier @ 2015-03-09 7:53 ` Jan D. 2015-03-09 10:38 ` martin rudalics 0 siblings, 1 reply; 34+ messages in thread From: Jan D. @ 2015-03-09 7:53 UTC (permalink / raw) To: Stefan Monnier, martin rudalics; +Cc: 19988, Tassilo Horn 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#19988: 25.0.50; Drag events ending in different frame 2015-03-09 7:53 ` Jan D. @ 2015-03-09 10:38 ` martin rudalics 0 siblings, 0 replies; 34+ messages in thread From: martin rudalics @ 2015-03-09 10:38 UTC (permalink / raw) To: Jan D., Stefan Monnier; +Cc: 19988, Tassilo Horn > XQueryPointer gives you the window. I suppose we just need the right Emacs window here. martin ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2015-03-09 10:38 UTC | newest] Thread overview: 34+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-03-03 14:30 bug#19988: 25.0.50; Drag events ending in different frame Tassilo Horn 2015-03-03 20:27 ` Eli Zaretskii 2015-03-04 4:28 ` Stefan Monnier 2015-03-04 7:03 ` Tassilo Horn 2015-03-04 17:22 ` Eli Zaretskii 2015-03-04 21:09 ` Tassilo Horn 2015-03-04 22:58 ` Stefan Monnier 2015-03-05 8:05 ` martin rudalics 2015-03-05 17:05 ` Eli Zaretskii 2015-03-05 3:37 ` Eli Zaretskii 2015-03-05 7:19 ` Tassilo Horn 2015-03-05 17:02 ` Eli Zaretskii 2015-03-05 20:07 ` Tassilo Horn 2015-03-05 20:15 ` Eli Zaretskii 2015-03-06 7:12 ` Tassilo Horn 2015-03-06 14:13 ` Eli Zaretskii 2015-03-06 16:09 ` Drew Adams 2015-03-06 18:55 ` martin rudalics 2015-03-05 17:00 ` Eli Zaretskii 2015-03-05 20:01 ` Tassilo Horn 2015-03-05 8:05 ` martin rudalics 2015-03-04 17:19 ` Eli Zaretskii 2015-03-04 15:10 ` martin rudalics 2015-03-04 21:14 ` Tassilo Horn 2015-03-05 8:06 ` martin rudalics 2015-03-06 14:37 ` Stefan Monnier 2015-03-06 18:55 ` martin rudalics 2015-03-06 20:19 ` Stefan Monnier 2015-03-06 21:31 ` martin rudalics 2015-03-07 0:49 ` Stefan Monnier 2015-03-07 9:41 ` martin rudalics 2015-03-09 4:34 ` Stefan Monnier 2015-03-09 7:53 ` Jan D. 2015-03-09 10:38 ` martin rudalics
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).