bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: martin rudalics
Subject: bug#31240: 26.1; mouse-save-then-kill does not kill rectangles
Date: Sat, 13 Oct 2018 10:18:49 +0200

> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]