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

[martin rudalics <rudalics@gmx.at>]

 > This is because after inserting the rectangle, the original rectangle
 > (which is to the left of the inserted one) is deleted. When it is
 > deleted, then the last 4 lines of the inserted rectangle are shifted
 > to the left:
 >
 > 1) Inserted new rectangle:
 >
 > ;;;;;;;;;;RECT;;;;;;;;;
 > ;;;;;;RECTRECT;;;;;;;;;
 > ;;;;;;RECTRECT;;;;;;;;;
 > ;;;;;;RECTRECT;;;;;;;;;
 > ;;;;;;RECTRECT;;;;;;;;;
 > ;;;;;;RECT;;;;;;;;;
 > ;;;;;;;;;;;;;;;;;;;
 >
 > 2) Deleted the original one:
 >
 > ;;;;;;;;;;RECT;;;;;;;;;  <--- this line isn't shifted
 > ;;;;;;RECT;;;;;;;;;
 > ;;;;;;RECT;;;;;;;;;
 > ;;;;;;RECT;;;;;;;;;
 > ;;;;;;RECT;;;;;;;;;
 > ;;;;;;;;;;;;;;;
 > ;;;;;;;;;;;;;;;;;;;

Thanks for the explanation.

 > I've thought up two ways of dealing with this problem:
 >
 > A) Forbid the user from dragging the rectangle to the right when the
 > new rectangle is *not* completly above or completly below the original
 > one. As an exception, allow the user to drag the rectangle purely to
 > the right (same line). In this option, the drag operation in your
 > example would not be permitted.  I think this option would be a bit
 > confusing for users (and too restrictive).

Agreed.

 > B) Add a variable mouse-drag-and-drop-rectangle-fill, initially set to
 > nil. When the variable's value is nil, the behaviour of dragging and
 > dropping rectangles is exactly the same as it is now. When it is set
 > to a non-nil value (for example, " "), then replace all characters of
 > the original rectangle with the variable's value. In this case, your
 > example would look like this:
 >
 > 1) M-: (setq mouse-drag-and-drop-rectangle-fill " ")
 >
 > 2) Inserted new rectangle:
 >
 > ;;;;;;;;;;RECT;;;;;;;;;
 > ;;;;;;RECTRECT;;;;;;;;;
 > ;;;;;;RECTRECT;;;;;;;;;
 > ;;;;;;RECTRECT;;;;;;;;;
 > ;;;;;;RECTRECT;;;;;;;;;
 > ;;;;;;RECT;;;;;;;;;
 > ;;;;;;;;;;;;;;;;;;;
 >
 > 3) Deleted the original one:
 >
 > ;;;;;;;;;;RECT;;;;;;;;;
 > ;;;;;;    RECT;;;;;;;;;
 > ;;;;;;    RECT;;;;;;;;;
 > ;;;;;;    RECT;;;;;;;;;
 > ;;;;;;    RECT;;;;;;;;;
 > ;;;;;;    ;;;;;;;;;
 > ;;;;;;;;;;;;;;;;;;;
 >
 > I can't think of any other way of ensuring the inserted rectangle
 > retains its shape after being inserted, if there are pending delete
 > operations to its left.

Let's keep B) in mind for the case that someone comes up with a real
use case where this would be needed.  Mine was just a constructed one
that looked convincing to me to to be reported.

The only remaining problem I have now is that we are far beyond the 80
columns limit for code.  I came up with truncating the assignment to
'drag-but-negligible' as follows

             (setq drag-but-negligible
                   (and (eq (overlay-buffer (car mouse-drag-and-drop-overlays))
                            buffer-to-paste)
                        (if region-noncontiguous
                            ;; If the region is rectangular, check if
                            ;; the newly inserted rectangular text
                            ;; would intersect the already selected
                            ;; region. If it would, then set
                            ;; "drag-but-negligible" to t.  As a
                            ;; special case, allow dragging the region
                            ;; freely anywhere to the left, as this
                            ;; will never trigger its contents to be
                            ;; inserted into the overlays tracking it.
                            (let ((size (cons region-width region-height))
                                  (start-coordinates
                                   (rectangle-position-as-coordinates start))
                                  (point-to-paste-coordinates
                                   (rectangle-position-as-coordinates
                                    point-to-paste)))
                              (and (rectangle-intersect-p
                                    start-coordinates size
                                    point-to-paste-coordinates size)
                                   (not (<= (car point-to-paste-coordinates)
                                            (car start-coordinates)))))
                          (and (<= (overlay-start
                                    (car mouse-drag-and-drop-overlays))
                                   point-to-paste)
                               (<= point-to-paste
                                   (overlay-end
                                    (car mouse-drag-and-drop-overlays))))))))

but that's ugly.  If you have any ideas how to handle that better (for
example, by moving the comment up by a few lines) I'll do that.
Otherwise, I'll have to use that form above.

Thanks, martin