Re: drag-and-drop failures

[Dave Love]

OK, I traced `x-dnd-drop-data'.  The first below is from dragging
`and' out of a Galeon window running on x86, and the second from the
same version running on sparc.

Assuming what I see there is what the application is really sending
(a) your guess was right; (b) the protocol is completely losing.  I
guess the only thing Emacs could do about it generally is to try to
decode as both utf-16be and utf-16le and see which produces least
U+FFFD, but I doubt that's worth it.  Presumably there should be a
note about this in PROBLEMS and the Emacs code should swap the bytes
on big-endian systems, since use between different systems will be
relatively rare.

Perhaps someone should check whether the behaviour is the same in
newer versions of Mozilla/Galeon.  I didn't manage to install a recent
Mozilla on our SPARC/Solaris or Irix systems for reasons I can't
remember and I can't update the Debian version.

[I edited the literal NULLs into `^@' here.]

======================================================================
1 -> x-dnd-drop-data: event=(drag-n-drop (#<window 3 on *scratch*> 192 (158 . 
130) 0 nil 192 (22 . 4) nil (158 . 78) (7 . 13)) ["XdndDrop" #<frame 
address@hidden 0x5a76e0> 32 [(480 . 974) 0 (43758 . 7445) 0 0]]) frame=#<frame 
address@hidden 0x5a76e0> window=#<window 3 on *scratch*> 
data=#("address@hidden@d^@" 0 6 (foreign-selection STRING)) type="text/unicode"
1 <- x-dnd-drop-data: private
======================================================================
1 -> x-dnd-drop-data: event=(drag-n-drop (#<window 3 on *scratch*> 192 (244 . 
94) 0 nil 192 (34 . 4) nil (244 . 42) (7 . 13)) ["XdndDrop" #<frame 
address@hidden 0x5a76e0> 32 [(234 . 37107) 0 (43758 . 25821) 0 0]]) 
frame=#<frame address@hidden 0x5a76e0> window=#<window 3 on *scratch*> 
data=#("address@hidden@address@hidden" 0 6 (foreign-selection STRING)) 
type="text/unicode"
1 <- x-dnd-drop-data: private