[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: drag-and-drop failures

From: Jan D.
Subject: Re: drag-and-drop failures
Date: Mon, 29 Mar 2004 17:55:37 +0200

It's good to see X drag-and-drop support added, but I think it needs
explaining what is expected to work.  Also, presumably the TODO item
on this can now be removed or be amended to say what still needs to be

I'll do that, thanks.  Does reading the Emacs manual about drag and drop
help to see what is supposed to work?

I can drag text successfully from KDE applications, but not from
Mozilla/Galeon, or OpenWindows.  I'm not surprised OpenWindows won't
work, but NEWS talks about drag and drop `under X' generally.

I know of six different drag and drop protocols under X, but Motif and
XDND are the most common.  I didn't want to confuse people in NEWS by
being too technical.  I planned to add OpenWindows, but I skipped that.
I don't use OpenWindows any more and it is on its way out, so the effort
does not seem worth it.

ASCII characters dragged from Galeon (built for GNOME) or Mozilla get
converted to U+FFFD in Emacs.

I can not reproduce this.  Did you start emacs with -q --no-site-file?
Also try setting the environment variable LANG and/or LC_ALL to C
before starting emacs and see if the problem is still there.
What version of Mozilla/Galeon/GNOME are you using.  I tried Mozilla
1.6, Galeon 1.3.7 on GNOME 2.4.

Dragging text from CDE dtpad (running on Tru64) to Emacs (on Debian)
crashes Emacs:

Is it only dtpad or any CDE application that craches Emacs?

Program received signal SIGSEGV, Segmentation fault.
0x70345b04 in _X11TransWrite () from /usr/X11R6/lib/libX11.so.6
(gdb) bt
#0  0x70345b04 in _X11TransWrite () from /usr/X11R6/lib/libX11.so.6
#1  0x70325ca4 in _XFlush () from /usr/X11R6/lib/libX11.so.6
#2  0x70327304 in _XReply () from /usr/X11R6/lib/libX11.so.6
#3  0x70322558 in XSync () from /usr/X11R6/lib/libX11.so.6
#4  0x000959a8 in x_catch_errors_unwind (old_val=5615712)
    at /dl/sr/homes/px/fx/esrc/src/xterm.c:7714
#5  0x00120dc0 in unbind_to (count=400, value=541020088)
    at /dl/sr/homes/px/fx/esrc/src/eval.c:3082
#6 0x00095b70 in x_connection_closed (dpy=0x661198, error_message=0x3ec400 "")
    at /dl/sr/homes/px/fx/esrc/src/xterm.c:7905
#7  0x00095db8 in x_error_quitter (display=0x661198, error=0xefffe6a0)
    at /dl/sr/homes/px/fx/esrc/src/xterm.c:7943
#8  0x00095dfc in x_error_handler (display=0x661198, error=0xefffe6a0)
    at /dl/sr/homes/px/fx/esrc/src/xterm.c:7958
#9  0x70329240 in _XError () from /usr/X11R6/lib/libX11.so.6
#10 0x70327660 in _XReply () from /usr/X11R6/lib/libX11.so.6
#11 0x7030eb70 in XGetAtomName () from /usr/X11R6/lib/libX11.so.6
#12 0x000aa4ac in x_atom_to_symbol (dpy=0x661198, atom=2157853552)
    at /dl/sr/homes/px/fx/esrc/src/xselect.c:290
#13 0x000ac788 in selection_data_to_lisp_data (display=0x661198,
    data=0x6095d0 "", size=18, type=4, format=536870911)
    at /dl/sr/homes/px/fx/esrc/src/xselect.c:1655
#14 0x000ac5e0 in x_get_window_property_as_lisp_data (display=0x661198,
window=37748766, property=305, target_type=541247376, selection_atom=1277)
    at /dl/sr/homes/px/fx/esrc/src/xselect.c:1574

Hmm, the atom passed to x_atom_to_symbol looks like garbage.  And the
type passed to selection_data_to_lisp_data is 4, which means Atom.
Atom is 4 bytes, but size is 18, not a multiple of 4.  Strange.
Can you do this again, and when it crasches, go up to stack frame 14
(x_get_window_property_as_lisp_data) and print out all local variables
as well as doing pr in gdb on the Lisp_Object variables and parameters?
This assumes you start gdb from the emacs/src directory.
I'll need the output from xlsatoms also.

It might be a 64 bit thing, but I am not quite sure how.


        Jan D.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]