Re: Drag and drop patch for X, please review.

[Jan D.]

> Which of these messages causes the Lisp-level drag-n-drop event?
> I would guess it is the last message that does so.

No, they all do.  That is, the messages the source sends: XdndEnter,
XdndPosition, XdndPosition and XdndLeave (mouse moved away from Emacs
or drop aborted).  The replies are sent from lisp with 
x-send-client-message.

All drag and drop protocols operate with XClientMessageEvent:s, so by
converting XClientMessageEvent to one Emacs event the protocol can be
totally implemented in lisp.  When adding Motif and others only lisp
code needs to be added (I hope :-).

>       Also, we are
>     not
>     selecting the buffers that the mouse travels over when doing a 
> drop,
>     so a local binding would have no effect if another buffer
>     is selected when the drag starts.
>
> The time to look up the proper key binding is when the drop *ends*,
> and only then.  It is not hard to get the key bindings for a given
> place on the Emacs frame.  We do that for mouse clicks, we could do it
> here too.

That is too late.  We must know if we are going to accept the drop 
before
it ends.  Otherwise we can not reply to the source that we are accepting
the drop, and if we are not accepting the drop, there will be no end
(i.e. XdndDrop) message, just an XdndLeave message.  The alternative is
to accept anything, but that is bad user interaction IMHO.  If we say
we accept the drop of a totally unknown type (application/funky-app for
example), we have no choice then but to signal an error when the 
XdndDrop
message occurs because we have no idea what funky-app is.
So basically we lied.  We said we could accept the data, but we really
couldn't, and we could have figured this out in advance just by looking
at the type.

I am currently using just one test function, that gets called when
a XdndPosition message arrives and something has changed (buffer, window
suggested action).  This function is called via a variable so it can be
changed.  The function returns the action and the type it wants to do
or nil to reject the drop.

In addition to that, there is an alist that maps types to
actions.  For example, text/uri-list defaults to open file for files
and calling the various browse-url handlers for non-file URLs.
text/plain defauls to insert.  But if someone wants to insert the file 
names
instead, they can change the alist entry for that type.  Or they can
make their own test function to always return text/plain if that is
available.

        Jan D.