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

[Federico Tedin]

> (if region-noncontiguous
>      (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)
>             (or (not (= (line-number-at-pos start)
>                         (line-number-at-pos point-to-paste)))
>                 (and (>= start point-to-paste)
>                      (<= point-to-paste (+ start (car size))))))))

Martin, I didn't manage to understand the condition you are testing:

(and (>= start point-to-paste)
     (<= point-to-paste (+ start (car size))))))))

If the first condition is true, the second will also be true (if
point-to-paste is smaller than start, point-to-paste will also be
smaller than start plus a positive integer).

> Maybe undoing the operation is more conservative the way we do it now:
> Currently, a first undo step would restore the original and a second
> step would delete the copy.  Otherwise, we would delete the copy first
> and then restore the original which would leave us with no clue of
> whatever the region contained after the first undo step.  Kunihiro-san
> could tell us more about this, maybe.

> I appreciate mouse-drag-and-drop-region when I move a sentence because
> the sentence never disappears from screen.  Based on this criteria,
> mouse-drag-and-drop-region inserts first and delete second.
> Practically it is quick, thus order does not matter much.

>From what I understand, these two explanations refer to the same
thing: it is better to have at all times the dragged region somewhere
in the buffer (even when undoing the drag operation). It would be best
to keep this behaviour in future versions of
mouse-drag-and-drop-region.

> There are two cases for dragging a sentence, that are ones with (1)
> deleting the original selection and (2) keeping it.  Since to insert
> is common for two cases, deletion of the original selection comes
> later.  If it works, order does not matter much.

I also agree with this, it is tidier to leave the optional operation
at the end.

> OTOH if reverting the order yields good results when moving the text
> to an intersecting but different line we could special-case the delete
> first/copy afterwards behavior on region-noncontiguous.

I'll check if I can come up with a better solution that best fits the
points that have been discussed above. If I can't, I'll check how
complex it would be to implement this special case at the end.