GNU bug report logs - #19988
25.0.50; Drag events ending in different frame

Previous Next

Full log

Message #8 received at 19988 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: 19988 <at> debbugs.gnu.org
Subject: Re: bug#19988: 25.0.50; Drag events ending in different frame
Date: Tue, 03 Mar 2015 22:27:31 +0200

> From: Tassilo Horn <tsdh <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.