GNU bug report logs - #31240
mouse commands not aware of rectangle regions

Previous Next

Full log

Message #130 received at 31240 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Federico Tedin <federicotedin <at> gmail.com>
Cc: 31240 <at> debbugs.gnu.org, homeros.misasa <at> gmail.com, tkk <at> misasa.okayama-u.ac.jp,
 charles <at> aurox.ch
Subject: Re: 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.