bug#18303: Drag and Drop fails when Emacs window/frame is above top

bug#18303: Drag and Drop fails when Emacs window/frame is above top

[Paulie Pena IV]

[-- Attachment #1: Type: text/plain, Size: 624 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 761 bytes --]

bug#18303: Drag and Drop fails when Emacs window/frame is above top

[Jan Djärv]

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.

bug#18303: Drag and Drop fails when Emacs window/frame is above top

[Paul Eggert]

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.

bug#18303: Drag and Drop fails when Emacs window/frame is above top

[Jan Djärv]

Hello.

7 sep 2014 kl. 21:50 skrev Paul Eggert <eggert@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.

bug#18303: Drag and Drop fails when Emacs window/frame is above top

[Paul Eggert]

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.

bug#18303: Drag and Drop fails when Emacs window/frame is above top

[Jan Djärv]

Hello.

8 sep 2014 kl. 15:10 skrev Paul Eggert <eggert@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.