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

Previous Next

Package: emacs;

Reported by: Tassilo Horn <tsdh <at> gnu.org>

Date: Tue, 3 Mar 2015 14:32:05 UTC

Severity: normal

Found in version 25.0.50

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 19988 <at> debbugs.gnu.org, tsdh <at> gnu.org
Subject: Re: bug#19988: 25.0.50; Drag events ending in different frame
Date: Thu, 05 Mar 2015 19:05:24 +0200
> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 19988 <at> 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.




This bug report was last modified 10 years and 155 days ago.

Previous Next


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