[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
- bug#31240: 26.1; mouse-save-then-kill does not kill rectangles, (continued)
- bug#31240: 26.1; mouse-save-then-kill does not kill rectangles, martin rudalics, 2018/10/06
- bug#31240: 26.1; mouse-save-then-kill does not kill rectangles, Federico Tedin, 2018/10/06
- bug#31240: 26.1; mouse-save-then-kill does not kill rectangles, martin rudalics, 2018/10/07
- bug#31240: 26.1; mouse-save-then-kill does not kill rectangles, Tak Kunihiro, 2018/10/08
- bug#31240: 26.1; mouse-save-then-kill does not kill rectangles, Federico Tedin, 2018/10/08
- bug#31240: 26.1; mouse-save-then-kill does not kill rectangles, martin rudalics, 2018/10/09
- bug#31240: 26.1; mouse-save-then-kill does not kill rectangles, martin rudalics, 2018/10/10
- bug#31240: 26.1; mouse-save-then-kill does not kill rectangles, Federico Tedin, 2018/10/11
- bug#31240: 26.1; mouse-save-then-kill does not kill rectangles, martin rudalics, 2018/10/12
- bug#31240: 26.1; mouse-save-then-kill does not kill rectangles, Federico Tedin, 2018/10/12
- bug#31240: 26.1; mouse-save-then-kill does not kill rectangles,
martin rudalics <=
- bug#31240: 26.1; mouse-save-then-kill does not kill rectangles, Federico Tedin, 2018/10/13
- bug#31240: 26.1; mouse-save-then-kill does not kill rectangles, martin rudalics, 2018/10/15
- bug#31240: 26.1; mouse-save-then-kill does not kill rectangles, martin rudalics, 2018/10/17
- bug#31240: 26.1; mouse-save-then-kill does not kill rectangles, Federico Tedin, 2018/10/18
- bug#31240: 26.1; mouse-save-then-kill does not kill rectangles, martin rudalics, 2018/10/19
- bug#31240: 26.1; mouse-save-then-kill does not kill rectangles, Federico Tedin, 2018/10/19
- bug#31240: 26.1; mouse-save-then-kill does not kill rectangles, Tak Kunihiro, 2018/10/10