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

[Federico Tedin <federicotedin@gmail.com>]

> Thanks!
>
> I tried this to test the patch:
>
> src/emacs -Q
> M-x set-variable RET mouse-drag-and-drop-region RET t
> With the mouse, drag from the "n" in "not saved" to the space after "C-x C-f" (in *scratch*)
> C-x SPC
> Now drag the region until the cursor is on the "a" of "and"
>
> For some reason, the region is not moved, and it gets re-activated as
> a normal region instead of a rectangular region.  Maybe I'm missing
> something obvious.  I was able to get the dragging of a rectangular
> region working sometimes, but not consistently.

I've tried your test, and it does break my fix, as you mentioned.

The problem was in the criteria used to define the variable
'drag-but-negligible'. The drag action used in your test was being
incorrectly marked as negligible. Because of this, the region was
also re-activated, but not in Rectangle Mark mode (this was also a bug).

I have made a correction where the variable 'drag-but-negligible' is
defined, so dragging a rectangle region outside of itself will no longer
mark it as negligible; and when it _is_ negligible, the region is
re-activated as a rectangle again.

I've also found some cases where the overlay list is not working well
enough to track the selected rectangle. For example, if a buffer
contains the following:

aaaa
BBbb
CCcc

Dragging a 2x2 square starting from the first 'B' (spaces added for
clarity):

 a a a a
[B B]b b
[C C]c c

to the column where the second 'a' is, results in the following:

a B B a a a
b b
c c

In this case, two 'C's are missing in the second line (after the first
'b'). The reason this is happening is the following: when
mouse-drag-and-drop-region is called, the initial overlays are the
following (shown with braces):

 a a a a
{B B}b b
{C C}c c

After the 2x2 square is inserted on the second 'a', the first overlay
is automatically expanded, because characters where inserted between
its start/end:

 a B B a a a
{b C C b}b b
{c c}c c

When the original text is then deleted (by deleting all overlays), the
result is:

a B B a a a
b b
c c

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, or find another way to track the
originally selected rectangle in a way it can be accurately deleted
after inserting it in the new position. I guess I'll go with the
second option, since it would make function more useful for users.