> > So I think I have two options now: either forbid the user from > > dragging a rectangle to a position where the inserted rectangle would > > intersect the original rectangle, > > IIRC that would be faithful to the original (non-rectangle-dragging) > design. > This second option sounds like it can be quite hard to define. If you > decide in the end to prevent the user from dragging the region > somewhere that would intersect with the dragged region (which, as > Martin said, is in line with the original design of > mouse-drag-and-drop-region) that would be fine. After trying out some solutions and reading these two suggestions, I've decided to implement the feature like this. The problem of correctly handling the cases where the dragged rectangular text would overlap with the original one was more complex than I'd thought, and I have some doubts if the usefulness of the feature justifies this added complexity. I'm attaching a new patch with all my changes to mouse.el (and rect.el) so far. I've created two new helper functions in rect.el to avoid cluttering mouse.el with more functions. So, the cases to test out are: 1) Dragging and dropping non-rectangular regions should be exactly the same as before. 2) Dragging and dropping a rectangle _outside_ of itself should insert it in the new position, and then delete the original. 3) Dragging and dropping a rectangle _inside_ of itself should leave everything unchanged. After evaluating "(setq mouse-drag-and-drop-region 'shift)": 4) Dragging and dropping a rectangle inside or outside of itself, while holding the Shift key when dropping, should insert it there, without deleting the original. When I say 'outside of itself' I mean that there shouldn't be any overlapping at all between the original and the newly inserted rectangles.