GNU bug report logs - #18303
Drag and Drop fails when Emacs window/frame is above top

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18303 in the body.
You can then email your comments to 18303 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Paulie Pena IV <paulie4 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Drag and Drop fails when Emacs window/frame is above top
Date: Wed, 20 Aug 2014 08:50:03 -0400

[Message part 1 (text/plain, inline)]

If my Emacs window is above the top of my screen (which is how I usually
have it since I don't care about the title bar, etc.), I cannot drag a file
onto the top part of the Emacs window/frame. If I try to, I get this error:
Not an in-range integer, float, or cons of integers

I traced the problem to the "XdndPosition" cond in x-dnd-handle-xdnd, which
calls x-send-client-message. The "list-to-send" variable has a negative y
value, which it gets from x-dnd-get-drop-x-y. I think the way to fix this
is to change x-send-client-message so it accepts negative x/y values, but
I'm not sure if that's correct.

Thanks,
Paulie

[Message part 2 (text/html, inline)]

Message #10 received at 18303-done <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Paulie Pena IV <paulie4 <at> gmail.com>, 18303-done <at> debbugs.gnu.org
Subject: Re: bug#18303: Drag and Drop fails when Emacs window/frame is above
 top
Date: Sun, 07 Sep 2014 19:32:57 +0200

Den 2014-08-20 14:50, Paulie Pena IV skrev:
> If my Emacs window is above the top of my screen (which is how I usually have
> it since I don't care about the title bar, etc.), I cannot drag a file onto
> the top part of the Emacs window/frame. If I try to, I get this error:
> Not an in-range integer, float, or cons of integers
>
> I traced the problem to the "XdndPosition" cond in x-dnd-handle-xdnd, which
> calls x-send-client-message. The "list-to-send" variable has a negative y
> value, which it gets from x-dnd-get-drop-x-y. I think the way to fix this is
> to change x-send-client-message so it accepts negative x/y values, but I'm not
> sure if that's correct.

This has been fixed in the trunk.  x-send-client-message accepted negative x, 
but did not accept negative y.

	Jan D.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 18303 <at> debbugs.gnu.org
Subject: Re: Drag and Drop fails when Emacs window/frame is above top
Date: Sun, 07 Sep 2014 12:50:38 -0700

Thanks for the patch.  I noticed that '(v1 << 16) | v2' wouldn't work as 
desired when v2 < 0, though, as v2's sign bits will bleed into v1's 
encoded value.  I installed an attempt at a fix as trunk bzr 117836.

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 18303 <at> debbugs.gnu.org
Subject: Re: Drag and Drop fails when Emacs window/frame is above top
Date: Mon, 8 Sep 2014 07:04:54 +0200

Hello.

7 sep 2014 kl. 21:50 skrev Paul Eggert <eggert <at> cs.ucla.edu>:

> Thanks for the patch.  I noticed that '(v1 << 16) | v2' wouldn't work as desired when v2 < 0, though, as v2's sign bits will bleed into v1's encoded value.  I installed an attempt at a fix as trunk bzr 117836.

Thanks, but it does not look right.  We can assume v1 and v2 are 16 bit signed integers (X coordinates).  In general, when data is a CONS, it must be two 16 bit numbers.
So (v1 << 16) | v2 is just a way of stuffing two signed 16 bits into 32 bits.
But when v2 is long,  (v2 & 0xffff) looses the sign bit, as the code is now.

I don't know why the range X_LONG_(MIN|MAX) >> 16 is relevant here, it is way too large.
Remember, val can only be 32 bit, so X_LONG_MAX >> 16 can in it self be 48 bits.
Maybe just convert v1 and v2 to two signed 16 bit numbers (int16_t?) and shift?

	Jan D.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 18303 <at> debbugs.gnu.org
Subject: Re: Drag and Drop fails when Emacs window/frame is above top
Date: Mon, 08 Sep 2014 06:10:31 -0700

Jan Djärv wrote:
> Thanks, but it does not look right.  We can assume v1 and v2 are 16 bit signed integers (X coordinates).  In general, when data is a CONS, it must be two 16 bit numbers.
> So (v1 << 16) | v2 is just a way of stuffing two signed 16 bits into 32 bits.
> But when v2 is long,  (v2 & 0xffff) looses the sign bit, as the code is now.

I don't see how the expression could keep the sign bit and still work. 
Suppose v1 == 27 and v2 == -1.  Then ((v1 << 16) | v2) == -1, and we've 
lost all information about v1's value.  In contrast, ((v1 << 16) | (v2 & 
0xffff) == 1835007 == 0x1bffff, so we still can retrieve information 
about v1's value by shifting this value right by 16 bits.

> I don't know why the range X_LONG_(MIN|MAX) >> 16 is relevant here, it is way too large.
> Remember, val can only be 32 bit, so X_LONG_MAX >> 16 can in it self be 48 bits.

X_LONG_MAX and X_LONG_MIN are always 32-bit values, even on platforms 
where long is 64 bits.  So the range X_LONG_MIN >> 16 .. X_LONG_MAX >> 
16 is -32768 .. 32767 which should be the correct range for X.

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 18303 <at> debbugs.gnu.org
Subject: Re: Drag and Drop fails when Emacs window/frame is above top
Date: Mon, 8 Sep 2014 17:18:38 +0200

Hello.

8 sep 2014 kl. 15:10 skrev Paul Eggert <eggert <at> cs.ucla.edu>:

> Jan Djärv wrote:
>> Thanks, but it does not look right.  We can assume v1 and v2 are 16 bit signed integers (X coordinates).  In general, when data is a CONS, it must be two 16 bit numbers.
>> So (v1 << 16) | v2 is just a way of stuffing two signed 16 bits into 32 bits.
>> But when v2 is long,  (v2 & 0xffff) looses the sign bit, as the code is now.
> 
> I don't see how the expression could keep the sign bit and still work. Suppose v1 == 27 and v2 == -1.  Then ((v1 << 16) | v2) == -1, and we've lost all information about v1's value.  In contrast, ((v1 << 16) | (v2 & 0xffff) == 1835007 == 0x1bffff, so we still can retrieve information about v1's value by shifting this value right by 16 bits.
> 

Yes, you are right.

>> I don't know why the range X_LONG_(MIN|MAX) >> 16 is relevant here, it is way too large.
>> Remember, val can only be 32 bit, so X_LONG_MAX >> 16 can in it self be 48 bits.
> 
> X_LONG_MAX and X_LONG_MIN are always 32-bit values, even on platforms where long is 64 bits.  So the range X_LONG_MIN >> 16 .. X_LONG_MAX >> 16 is -32768 .. 32767 which should be the correct range for X.

Right, I missed the X_.

	Jan D.

Previous Next

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