bug#31240: 26.1; mouse-save-then-kill does not kill rectangles

[Federico Tedin <federicotedin@gmail.com>]

> FWIW I see no problems with the following naive amendment
>
>                             (let ((size (cons region-width region-height)))
>                               (and (rectangle-intersect-p
>                                     (rectangle-position-as-coordinates start) size
>                                     (rectangle-position-as-coordinates point-to-paste) size)
>                                    (not (= (line-number-at-pos start)
>                                            (line-number-at-pos point-to-paste)))))
>
> which also allows shifting the rectangle strictly to the left or
> right.  IIUC it's the deletion of the original rectangle after the
> copy was inserted on a different line that's causing havoc with
> intersections.  But I have not tested all possible variants so please
> correct me if I'm wrong.

The problem with this is that when the rectangle is inserted to the
right of the original one, it is inserted inside the overlays tracking
the selected rectangular region. When the original rectangle is then
deleted (by deleting the overlays), the newly inserted rectangle is
also deleted. You can try this by dragging a rectangle 1 char to the
right.

This problem exists because mouse-drag-and-drop-region first inserts
the dragged contents, and then deletes the original selection. Is
there a reason this has been implemented like this? It sounds like it
would make more sense to first delete the original selection, and then
insert it elsewhere. This would be almost the same as killing and then
yanking some text. That being said, for non-rectangular regions, any
of the two methods works the same.