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

Previous Next

Full log

View this message in rfc822 format

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: bug#31240: 26.1; mouse-save-then-kill does not kill rectangles
Date: Sun, 07 Oct 2018 08:17:09 +0200

> The problem with this is that when the rectangle is inserted to the
> right of the original one, it is inserted inside the overlays tracking
> the selected rectangular region. When the original rectangle is then
> deleted (by deleting the overlays), the newly inserted rectangle is
> also deleted. You can try this by dragging a rectangle 1 char to the
> right.

You're probably right, I have no knowledge of the rectangle code.
Another naive try: Disallow inserting the rectangle in the first row
of the original because that case is almost identical to that of
inserting a contiguous region into itself.

(if region-noncontiguous
    (let ((size (cons region-width region-height)))
      (and (rectangle-intersect-p
            (rectangle-position-as-coordinates start) size
            (rectangle-position-as-coordinates point-to-paste) size)
           (or (not (= (line-number-at-pos start)
                       (line-number-at-pos point-to-paste)))
               (and (>= start point-to-paste)
                    (<= point-to-paste (+ start (car size))))))))

> This problem exists because mouse-drag-and-drop-region first inserts
> the dragged contents, and then deletes the original selection. Is
> there a reason this has been implemented like this? It sounds like it
> would make more sense to first delete the original selection, and then
> insert it elsewhere. This would be almost the same as killing and then
> yanking some text. That being said, for non-rectangular regions, any
> of the two methods works the same.

Maybe undoing the operation is more conservative the way we do it now:
Currently, a first undo step would restore the original and a second
step would delete the copy.  Otherwise, we would delete the copy first
and then restore the original which would leave us with no clue of
whatever the region contained after the first undo step.  Kunihiro-san
could tell us more about this, maybe.

OTOH if reverting the order yields good results when moving the text
to an intersecting but different line we could special-case the delete
first/copy afterwards behavior on region-noncontiguous.

martin

Previous Next

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