unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#18303: Drag and Drop fails when Emacs window/frame is above top
@ 2014-08-20 12:50 Paulie Pena IV
  2014-09-07 17:32 ` Jan Djärv
  2014-09-07 19:50 ` Paul Eggert
  0 siblings, 2 replies; 6+ messages in thread
From: Paulie Pena IV @ 2014-08-20 12:50 UTC (permalink / raw)
  To: 18303

[-- 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 --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#18303: Drag and Drop fails when Emacs window/frame is above top
  2014-08-20 12:50 bug#18303: Drag and Drop fails when Emacs window/frame is above top Paulie Pena IV
@ 2014-09-07 17:32 ` Jan Djärv
  2014-09-07 19:50 ` Paul Eggert
  1 sibling, 0 replies; 6+ messages in thread
From: Jan Djärv @ 2014-09-07 17:32 UTC (permalink / raw)
  To: Paulie Pena IV, 18303-done

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.







^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#18303: Drag and Drop fails when Emacs window/frame is above top
  2014-08-20 12:50 bug#18303: Drag and Drop fails when Emacs window/frame is above top Paulie Pena IV
  2014-09-07 17:32 ` Jan Djärv
@ 2014-09-07 19:50 ` Paul Eggert
  2014-09-08  5:04   ` Jan Djärv
  1 sibling, 1 reply; 6+ messages in thread
From: Paul Eggert @ 2014-09-07 19:50 UTC (permalink / raw)
  To: Jan Djärv; +Cc: 18303

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.





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#18303: Drag and Drop fails when Emacs window/frame is above top
  2014-09-07 19:50 ` Paul Eggert
@ 2014-09-08  5:04   ` Jan Djärv
  2014-09-08 13:10     ` Paul Eggert
  0 siblings, 1 reply; 6+ messages in thread
From: Jan Djärv @ 2014-09-08  5:04 UTC (permalink / raw)
  To: Paul Eggert; +Cc: 18303

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.






^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#18303: Drag and Drop fails when Emacs window/frame is above top
  2014-09-08  5:04   ` Jan Djärv
@ 2014-09-08 13:10     ` Paul Eggert
  2014-09-08 15:18       ` Jan Djärv
  0 siblings, 1 reply; 6+ messages in thread
From: Paul Eggert @ 2014-09-08 13:10 UTC (permalink / raw)
  To: Jan Djärv; +Cc: 18303

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.





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#18303: Drag and Drop fails when Emacs window/frame is above top
  2014-09-08 13:10     ` Paul Eggert
@ 2014-09-08 15:18       ` Jan Djärv
  0 siblings, 0 replies; 6+ messages in thread
From: Jan Djärv @ 2014-09-08 15:18 UTC (permalink / raw)
  To: Paul Eggert; +Cc: 18303

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.








^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2014-09-08 15:18 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-08-20 12:50 bug#18303: Drag and Drop fails when Emacs window/frame is above top Paulie Pena IV
2014-09-07 17:32 ` Jan Djärv
2014-09-07 19:50 ` Paul Eggert
2014-09-08  5:04   ` Jan Djärv
2014-09-08 13:10     ` Paul Eggert
2014-09-08 15:18       ` Jan Djärv

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).