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.
>
> If all of them turn into Lisp events, then all of them could be 
> customized
> to depend on any aspect of the environment.  But why bother to make
> a Lisp event for anything except the actual drop?  I can see that is
> more flexible, but it could be much slower.

Yes, it is much more flexible.  There have never been a stable common
drag and drop protocol for X, so I fully expect them to change.
Some things, such as what types of drop data to accept, are much easier
to customize and handle in lisp than in C.  It is not nice to
say that we accept anything and then either raise an error because
the data could not be handeled, or just ignore the data because nothing
took care of the final drop event.

The slowness is mostly the sending of events through the X server
anyway.

> > 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.
>
> I think it is acceptable to always accept the drop, when the pointer
> is on a buffer text area.

I disagree, it goes against the whole point of having a protocol in the
first place.  Applications should accept drops they know they can 
handle,
anything else is to confuse the user.

> However, since you've implemented Lisp events for all the messages
> in the drag-n-drop protocol, I guess it ought to be easy enough
> to make the Lisp code that handles the event run some function
> provided by the major mode in order to decide whether a drop
> is acceptable at a given point.

This is my current approach, but the function is called through a
variable that can be made buffer local if so needed.

        Jan D.