mouse-drag-and-drop-region

[martin rudalics]

Sorry for reacting late to the addition of ‘mouse-drag-and-drop-region’
but it never worked with multiple windows here so I had to find the
source of that problem first.  It turned out that having
‘mouse-autoselect-window’ non-nil interferes, because whenever the mouse
enters another window, a 'select-window' event will be generated which
the code should ignore.  I now installed the necessary change.

The code should ignore ‘switch-frame’ events too.  But this won't
accomplish much at the moment because to drag text from one frame to
another we need additional provisions.  In principle, Emacs should
always avoid switching frames during and after mouse tracking but I'm
not yet sure how to do that consistently.

Anyway, here are some comments:

(1) Why does the value selection happen within the ‘track-mouse’ form
    and why do you delete the mouse overlay?  That is, why don't we move
    this part

        (unless value-selection ; initialization
          (delete-overlay mouse-secondary-overlay)
          (setq value-selection (buffer-substring start end))
          (move-overlay mouse-secondary-overlay start end)) ; (deactivate-mark)

    right to the beginning so we have something like

  (let* ((start (region-beginning))
         (end (region-end))
         (point (point))
         (buffer (current-buffer))
         (window (selected-window))
         (value-selection (buffer-substring start end)))
    (move-overlay mouse-secondary-overlay start end)
    (track-mouse
      ...

    there?

(2) Activating the secondary overlay can be distracting and should be
    made optional (facultatively keeping the primary overlay in place
    provided (4) below is done).

(3) Showing tooltips can be distracting and should be optional.  Note
    also, that usurping tooltips this way may prevent them from showing
    interesting properties of the drop area like whether the text there
    is read only.  OTOH we might consider retaining properties of the
    text in (non-GTK) tooltips.

(4) The (deactivate-mark) and (mouse-set-point event) trick to allow
    showing point the way ‘mouse-drag-track’ does can be distracting and
    should be made optional.

(5) The mouse pointer shape should take care of indicating the exact
    position where the drop occurs.  We should probably also signal
    whenever the current drop position is invalid.  This is IIUC usual
    practice on most window systems now.

(6) Dropping should allow to copy text into the region itself.  There's
    no reason forbidding that.

(7) IMO either cutting should be the default too when the drop occurs in
    a different buffer or copying would be the default and pressing the
    modifier should produce a cut instead.  The current behavior wants
    me to always keep in mind whether the target buffer is the same as
    the source buffer.  At least, this behavior should be made optional.

(8) Read-only text should be handled.  An attempt to drop text into a
    read-only area should be signalled to the user.  An attempt to cut
    text from a read-only text/buffer should be signalled as well.

(9) The code must become resilient against any failures by wrapping it
    into a ‘condition-case’ and doing the necessary clean up operations
    (restoring region and point, deleting the secondary overlay).

I think (8) and (9) should be fixed before the release.  As for future
releases we might also consider a ‘set-transient-map’ based solution.

Sincerely, martin