Re: mouse-drag-and-drop-region

[martin rudalics <rudalics@gmx.at>]

 > Indeed.  It should probably be generalized for uses where that's not
 > appropriate (similarly for uses where the mark shouldn't be modified
 > (not even temporarily)).  E.g. for mouse-drag-secondary.

Tracking the mouse and keeping the region intact is impossible unless we
continuously synchronize the position of point and the mouse cursor.
Anything else would invalidate the region as soon as scrolling the
window moves point.  So unless we allow alternative semantics of the
"region" 'mouse-drag-track' will have to modify the region as it does
now.

Note in this context that the doc-string of 'mouse-drag-track'

     "Track mouse drags by highlighting area between point and cursor.
The region will be defined with mark and point."

is completely misleading.  It should start with a line like

"Track mouse drags by synchronizing point with the mouse cursor."

where we could explain that "synchronizing" means something like moving
point to the most nearby buffer position corresponding to the current
mouse position on the screen and that dragging leaves the mark unchanged
and the highlighted region will change accordingly.

Obviously, we can give 'mouse-drag-track' an extra argument which
'mouse-drag-region' (and 'mouse-drag-secondary') would set appropriately
to tell it how to handle the region.  Before doing that we should,
however, establish the canonical way to handle mouse tracking.  More
precisely, we should decide whether we prefer the 'track-mouse' plus
'read-event' approach or the 'set-transient-map' one.  Currently, this
doesn't seem entirely clear to me.

martin