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

[Charles A. Roelli]

> From: Federico Tedin <federicotedin@gmail.com>
> Date: Sun, 23 Sep 2018 19:23:13 -0300
>
> You're right about mouse-drag-and-drop-region, it doesn't work
> correctly when using rectangular regions. After taking a look at the
> code, I managed to fix two things: the dragged text now has the
> correct rectangular contents (but the original text is incorrectly
> deleted using a normal region)

Would it be feasible to replace calls to "delete-region" with the
right call to "region-extract-function"?  Even though the current
arguments to "delete-region" in "mouse-drag-and-drop-region" are based
on the position of "mouse-drag-and-drop-overlay", this should not pose
an issue.

>                               , and the tooltip displaying the dragged
> text also shows the correct contents.
> 
> To fix the rest of the functionalities, I would need to know the
> recommended way of handling some of the details of how
> mouse-drag-and-drop-region is implemented:
> 
> - The dragged region is tracked using an overlay. From what I
>   understand, this is a problem since overlays only handle regions
>   with a single beginning and end, and rectangles have one or more of
>   those.

We should be able to keep using the overlay for normal regions, and
adapt mouse-drag-and-drop-region to use "apply-on-rectangle" with the
rectangle bounds as an argument when it needs to do something with a
rectangular region.

> - In order to check if the dragged text is read-only, the function
>   "next-single-char-property-change" is used. This function has the
>   same problem as the overlay, as it assumes the region is contiguous.

I think "apply-on-rectangle" could be helpful here too.
 
> I'm thinking both problems could be solved by using a list of overlays
> instead of just one, creating them from the result of calling
> "region-bounds".  Then, the rest of the function could be adapted to
> use the overlay list.

Yes, this would work too.